|
Yes, the owner is begging for an agile project here!! Agile is the type of development he's wanting and heck, OP, why not go that route? The OP could start with this screen the owner designed that does nothing actually behind the scenes, sure, but is what he (and hopefully other users! understand and want). Then you say, ok, what part do you want me to work on in the first 2 weeks? He tells you and you go work on that. You bring back to him in couple weeks what you have and repeat. When he sees that in the 3rd sprint as you all get deeper into it that you have to now rework stuff from sprint 1 or 2, and that it will take some time to do that in the current sprint, he might start seeing how you being told stuff up front, at some base level of knowledge shared, will be beneficial to him as well.
Now, you have a very valid concern about the business domain. ..understanding that so you know how to design (re-design) the database. .no getting around that. But maybe you could make class objects for now and use those, then you'd learn as you go what these are and how they relate, and these become your tables. Dunno, but I agree with those saying you'll find it very difficult not operating iteratively like he's asking and there are good aspects to this as well.
|
|
|
|
|
Please tell me you don't "develop" line of business apps like that??
After 35+ years of designing and writing code, that approach just doesn't work.
This guy has a problem in that his boss doesn't understand that HE needs to be a teacher as well and educate him on how the business processes work. Without that, you've got a "pretty" screen that looks good to him but is utter confusion behind those fields.
I've heard it referred to it as "putting a dress on a pig".
|
|
|
|
|
Dave Kreskowiak wrote: This guy has a problem in that his boss doesn't understand that HE needs to be a teacher as well and educate him on how the business processes work
Could be but a top level screen is in fact exactly one place to start doing that.
|
|
|
|
|
Have you looked at comparable applications to see what they do? Study your competition, at least the successful ones.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Perhaps one way to communicate with your boss is to write an email laying out your concerns in an objective manner.
However, as jschell has pointed out, he's paying you to do the job he tells you to, not the one you think you ought or want to be doing. Bite the bullet and get on with it and stop moaning - he isn't paying you to think, evidently.
Besides, if he likes what he sees who are you to second guess him? It's his dime.
If your real concern is how a poor outcome will look to the boss and on your resume then you should consider leaving and going somewhere where you can do it your own way.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Actually I disagree with you to a degree, IMHO you MUST go for the best outcome, the OP has obviously exhausted his own ideas and is looking for new ones. Just buckling under and creating rubbish (what the owner wants) knowing it will be a disaster is wrong.
He needs to push back on the owner, whether with education or just being a more stubborn bastard or both, but it needs to be done. Worst case is he gets fired so this must be mitigated by the OPs personal situation.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Well stated.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Yeah, can't see that working here. The op is plainly not willing/able to challenge the owner so he has few choices. At the end of the day if the man that pays your wages says do it my way and won't listen to your opinion you either do it or walk.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Got to agree, if he hires a developer and then refuses to give the guy the information he needs to do his job then walking seems to be the only option. The OP has got to make the decision if he wants to work under those conditions and then shove a rocket up the owner on the way out.
I've done that a couple of times over the years with mixed results, sometimes calling the guy a bloody idiot on the way out works.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: and creating rubbish (what the owner wants) knowing it will be a disaster is wrong.
Just to be clear there is nothing that suggests to me that the suggested application is absolutely "rubbish".
It might be. But lacking real knowledge of the actual business processes that are being modeled it is rather hard to state that. And from the question posted the OP doesn't know what those business processes are either.
Mycroft Holmes wrote: He needs to push back on the owner,
Or he creates the application. And then the user(s) start wondering what else is possible and then that gets added in the next version.
|
|
|
|
|
You are in pretty deep here. I think you may have missed a few opportunities along the way notwithstanding the personality of the owner.
Were you hired to implement this ERP?
What are the goals of this project?
Does the owner understand the concept of requirements gathering or does he think you have all you need by looking at the existing one? In that case has he been given any idea of what a new system could offer.
Are you fixated on some methodology?
If he wants to work with screens I would have started by storyboarding the screens. This is often a good way of involving difficult actors and is a requirements gathering process.
Many projects start in this way and follow a loosely Agile methodology.
If he yells at you for asking questions, hell I don't know. Where to from there? If that is really the case you have hit a brick wall I would suggest because you are going to need his support.
In the end you must take control while satisfying the owner that progress is being made.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
As some others have said...
Also my 2c
It seems to me that communication between you and your boss is the heart of the problem - he (quite reasonably) just wants something built but doesn't want to take the time or effort to think about it too much.
You (quite reasonably) want to analyse the requirements and build something suitable.
I tend to 'play dumb' in these cases. what you want is for the owner (or some member of staff) to show you what they need to do. So ask - find out who will be using it and ask if you can sit down with them to work out what to do. Admit to dealing in the unknown, and flatter them (they have superior knowledge - maybe they can pass on just a little to you, a mere mortal)
Also, get agile!
Mock up a first screen - you will probably have to do one like that that has been designed to not appear negative - and ask to sit with the boss, or users (preferably both) so that they can explain to you how it will work - because they are the experts.
Then build, one step at a time, better and better models. It will be more work than would be the case if they could explain it to you up front - but they don't see that (and sounds like they won't!)
If you can sit them down, with the app open, with a billion fields, and start working through it, hopefully you will both learn something for the better, and you can re-model.
Knocking up a does-nothing but looks nice view shouldn't be too time consuming - and you can treat it as a scribble-on-paper diagram - something to start the ball rolling...
Good luck!
MVVM # - I did it My Way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011
.\\axxx
(That's an 'M')
|
|
|
|
|
In my humble opinion, you're between a rock and hard place. If he is the owner you describe, you've got about a 1 in 6 chance of turning this around.
The only play you've got is to sit this guy down and lay out how the development process works. The business processes are the foundations of the house represented by this project. The "screens" he wants are the "roof" on this house. Where does it make sense to start building this house so the doesn't fall to the ground?
Yes, you MUST mention the possibility of failure if things continue the way they are, repeatedly. Nothing will get his attention more than spending more money than he wants on this project.
If he continues to try and wiggle out and not cooperate, you're going to be on the street, whether you walk out the door or the project fails for lack of business support.
If you're thinking of going behind his back and interviewing everyone on their business process, good for you, but prepare for possible retaliation if he finds out.
It's up to you now. Plan for the worst case outcome and hope for the best.
Good luck to you.
|
|
|
|
|
Isfeasachme wrote: Just wire it up like the owner wants and let the flaws become self-evident?
Unfortunately you will be blamed for the flaws when they become self-evident.
Mock up the first screen and then sit down with the boss and a trusted member of the people who actually use the system and show them the monstrosity.
Hopefully you can convince them of the need to streamline the screen content and work from there.
If that doesn't work face the fact that your skills will never be appreciated and start looking for a better match where you can contribute to the process.
|
|
|
|
|
Whatever you do if you do bite the bullet and do it his way; make sure it's on paper that he turned down your expertise with his signature.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Some very good advice from the others so far.
I find it helps to have a few real-world analogies at hand to illustrate the need for analysis and planning.
For example you could take the example of a company ordering a fleet of trucks and then finding out that the pallets you use don't quite fit 4 abreast so you lose 25% delivery capacity. The solution is to either replace the whole fleet (expensive) or redesign the pallets (non-standard solution) with a knock-on effect on product package sizes as a whole.
I'm sure that you can come up with something suitable for his mind-set.
|
|
|
|
|
Nice analogy, great example to describe to non-techies of how software development can be affected by failure to get as much info up front as possible.
|
|
|
|
|
Your boss is getting annoyed with you and that's never a good thing. Unfortunately your hope of a fresh analysis and redesign is, for now, off the cards.
Going by his response to the designers work it sounds like your first port of call should be to port the whole app to .net. I know this sounds awful but there should be some quick(?) wins for the users; nice shiney new UI for a start, not to be underestimated. Also, you will get a good understanding of how the old system works which should hint at how the business works and you'll learn a great deal.
Then, off your own bat and possibly in your own time, identify a section of the app/business that is rife for a redesign and just do it. It looks like you have pretty much free-reign as long as you start producing something.
If feedback is good for that piece, better still if users start suggestion slight alterations that can be done quickly and easily then the bossman should recognise that the redesigned area is better and can bring efficiencies to his business.
From the sounds of it the only way you can convince your boss the merits of well designed software is to just do it. You need to pick a pice that you can redesign quickly, basically without him noticing, and let the result win him round.
Greg
|
|
|
|
|
gregfarnan wrote: the bossman should recognise that the redesigned area is better and can bring efficiencies to his business
The boss sounds like a bully who will never be satisfied unless he comes up with the idea.
To some people teamwork is a lot of people doing what they say to do.
|
|
|
|
|
Clearly, you and your boss do not "see eye to eye". You and your boss cannot communicate with each other. I am blaming neither you nor your boss. But you should quit your job. This is the best thing you can do. Otherwise, you will be perpetuating a bad situation that should better stop.
|
|
|
|
|
I admire your intention to make it work.
My first impression is that there are two optiones
after an initial preparation:
The initial prep is to study the application how it is working right now, ...
because it seems that nobody wants to explain it to you.
Option 1: start programming in small steps which allow to present it to the boss.
Each step allows for correcciones/adjustments.
Option 2: find an open source project which serves your needs.
Install, learn and present it to the boss.
Explanation:
- I added the preparation because even the boss does not know what he wants.
I have been in similar projects. You have to study the "actual" situation
thoroughly. I did not do that, and the project took several months longer,
because the adjustments took much time !
- Option 1: takes much time. Explain to the boss !
- Option 2: Gives you a quick start ! I have experience with this one too.
A project which costs several years to develop, took me some months to implement.
The users have a lot of requests, but hey  easy to add features, because
the source is included and as a programmer, you know: we can program
almost anything. The example I refer to is a web-application:
programmed in php, with mysql database running on apache.
|
|
|
|
|
You need to learn how to manage your boss. This means understanding his personality and working with it. He sounds like a no nonsense talk is cheap type of personality. He hired you to be a programmer and replace their failing DOS-based ERP with an ASP.NET soluttion. He did not hire you to ask a lot of questions. If he wanted to pay someone to ask lots of questions he would have hired his worthless son-in-law. You need to tell him what you are going to do. For example I would state "The first screen is going to do this!" He might reply "That's BS! It has to work like this." and the conversation is started. IMHO I think you really should feel fortunate. Your boss is saying you are the expert programmer and he is willing to give you control. If you tell him what you are going to do instead of asking him what you should be doing things should get better. He will let you know when he does not like what you are telling him. Later in your career you may have a boss that wants to participate in all the decisions and will love that you ask them everything.
|
|
|
|
|
Sounds like a "Bring me solutions not problems" kind of guy. The Graphic artist has given him a solution, you've given him problems. So yeah, he likes whatever foul creation was handed to him because it's at least something.
Take the graphic designer, go talk to some end users on just what the process they go through is. If the designer's approach really is how they work swallow some pride and squeeze the code out, if it isn't then start designing the work flow that needs to be produced and have the designer put together some mock screens for it. Run that past the users, if they like it run with it, if they hate it burn it and start over, if they have a few suggestions integrate them. If there's a lot of change do it all again, but one way or another find a way to make progress that gives the owner something to look at rather than questions to answer.
Trying to get answers from such people is like pulling teeth, it's easier to get them to tell you what they do when they run through the process than get them to tell you want they want the process to be. But, if you present them with something that requires less screwing around in their process they'll respond well. Then of course you have to dig out the edge cases no one mentioned, but at least that's a later problem.
|
|
|
|
|
I have been (and still am) in a very similar situation, and I suggest that you avoid being "subversive" - I get the impression from your post that your boss likes to have his fingers in all the pies - so if he feels you are undermining him or taking your own path on this, he will move to block you, and you will find the whole experience even more frustrating.
If you can, find someone who has the boss's trust, convince them of the merits of your approach and the reasoning behind it, and use their support to convince the boss to allow you the leeway to get moving.
Once your champion is on board, pull together a small team, which includes this person, you, the designer, and at least one representative from the end users (you can change the representative(s) at different phases of the project). Start with the designer's layout, and start chopping it into discrete functions - as others have suggested, it's best to take an educator's role on this and let the users and the designer figure out the bulk of the issues, while you take notes, provide technical guidance and ask leading questions, when appropriate.
Most of all, provide the boss with regular summaries of progress, without too much detail, and at the same time without being evasive.
Good luck!!
|
|
|
|
|
Your bos is right. It's your opportunity to learn something most if not all programmers do not understand: That "normal" (the majority of) people do not think like programmers.
The opportunity and reword can be significant -- way beyond this project.
Here are the exact step to take.
1. Using GUI tools (as an example Win API based tools) recreate the DOS program interface, display and functionality to GUI. Provide identical functionaly and interface but convert the infrastructure such as database to your final platform -- as an example a relational database such as MYSQL or MS SQL instead of a DOS based databse system.
2. Get the users and owner to "test" the new system -- do not add features at this stage - but list notes, comments, criticism and requests for new functionality.
3. Implement regression and intrval backup as well as the web infrastructiure for exapnsion.
4. After testing move to parellel usage of both the old and new systems.
5. After testing comleted move the entier operation to the new system.
6. Start your designe process for new features based using what you have leanred.
7. Start adding new features, one by one with incremental regression.
Feel free to contact me for tools that were designed to do just that. m@views.com
Thank you.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
