|
If you honestly want to salvage the situation you will have to become an educator.
Teach the designer how to design. The the staff how to communicate their needs to the designer (teach them how critical this is to their future). Teach the boss how to understand your needs.
Make sure things are very iterative and goals/milestones are easily reached and reviewed frequently (buzzword - agile).
Make sure your communication is very simple and to the point (nobody seems to want or is capable of details). Only ask questions that require simple answers.
Also, one last thing... communicate to him there are two kinds of knowledge you need as a developer:
1. Technical knowledge (which he is paying you for)
2. Domain/Business knowledge (which makes your tech skills more valuable to him as you can work more effectively)
Domain/Business knowledge are things like "defense industry", or "medical IT", or "Retail and Point of Sale". Developers with the appropriate domain knowledge are critical for closing the gap when the business analist is missing or misses details.
|
|
|
|
|
Excellent response. Thank you.
|
|
|
|
|
Something like:
"We can develop the code for the first screen as the designer has shown and then spend time to modify it for the changes that we know we'll need,
OR
we can spend some time up front to figure out exactly what we really want it to do and then develop that.
The second way is almost certainly going to cost less!
I admit, the second way will feel like we're not making any progress for awhile, but knowing what we're actually aiming for means we won't be wasting time and money working on the parts we'll change anyway."
|
|
|
|
|
Spot on - but you would be amazed by how little sense that would make to the owner.
I found out after I was hired that he turned down a vendor for this project because they brought a big roll of butcher block paper and started mapping the old database. He said he didn't want to analyze and plan the thing to death, he just wanted to get going.
I winced and said, "But... that's what you do!"
I tried to explain "agile development" to him. He loved the idea until he realized that I'd still have to do planning and analysis before I started coding. 
|
|
|
|
|
I find it difficult to believe that a successful small business owner wouldn't understand wasting money. (But I haven't met him, so...)
If you can get a bit of the company's early history, relate it to the analysis he did before he committed to starting this particular business.
|
|
|
|
|
It's the old aphorism - if you fail to plan, you plan to fail.
|
|
|
|
|
Is sounds like that is going to go down really well with this bloke!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Isfeasachme wrote: How would you turn this into a win?
The user of the system told you how they wanted the system to work (the UI is the 'system' to them.)
They suggested that you start with the first screen so they could look at it.
Someone did a mock up and the user liked the mock up.
And you don't like it.
I must be missing something because the only problem I see in the above is you.
Perhaps your description left out that the boss isn't actually a user of the system and doesn't in fact know how it is used? Hopefully that is it.
|
|
|
|
|
So, you can tell how a system works and what the rules behind it are just from a mockup? Wow, that is some talent you have there. Personally, I like to explore something called the use cases, but I'm quaint like that. You know, those things such as if I press a button here, what happens next.
|
|
|
|
|
Pete O'Hanlon wrote: So, you can tell how a system works and what the rules behind it are just from a mockup? Wow, that is some talent you have there. Personally, I like to explore something called the use cases,
Myself I would prefer to have all the business requirements handed to me by a knowledgeable business analyst who has had a lot of previous experience both in the company, the industry and with writing business requirements.
But I gave up on fantasy scenarios a long time ago (and I can assure you that it wasn't easy.)
But in the mean time the OP stated that the person with the knowledge will NOT do what you are suggesting. And the OP isn't willing to quit either.
So exactly where do you think that these two individuals are going to start?
|
|
|
|
|
LOL I see it is your turn to be "that guy". Sorry -- This is not the thread for you.
|
|
|
|
|
Your response will not earn you points. I've learned the hard way that the response is right on. If you fail to see that, then perhaps programming is not for you.
Gus Gustafson
|
|
|
|
|
Although I don't agree with the tone of the answer, I do kind of agree with the message.
I think you're trying to play basket ball with foot ball rules. He obviously is not interested in going a "traditional" route of explaining every intricacy of the application, go through all the hypothetical scenarios, and mentally building the solution in his head and envisioning it before you code. The thought that you could change that is, in my opinion, wrongheaded and doomed to cost way more in the long run, contrary to what people are saying here.
I think the teachable moment here is indeed for you, not him. This is a good example of why "traditional" methods perform very poorly, and why an "iterative", and more so "lean", approach is a better tool for this job.
DO take this mock up and DO create a, more or less, wireframe app around it. Do this quickly and do not think too much about it. You will find that by giving him a more concrete example of the application and flow you will learn much more and much faster. Once he sees it for his own eyes and does not have to think abstractly about the application, I think you'll find that he will describe it more and more. Perhaps even create that fast screen, and after that, do think about it and create a different screen with things tweaked in the direction you'd like to take things as you see them now. He'll tell you where you are right and where you are wrong.
If everyone had the ability to visualize a complex system like you are building (why you building one rather than buying one would be my first question, anyways) then no one would need your skills. His skills are obviously more interpersonal or sales related. I'm not sure what mix you have, but I think the FIRST thing you need to realize is that you CANNOT change someone fundamentally. You need to look at things differently and seriously challenge yourself to find a way to take his strengths and utilize them, rather than fix his weaknesses. (Hmmm... I think there's a book about that... right?  )
|
|
|
|
|
Well said, @cwmillerli!
Some kind of Upside Down Aikido Programming...
Here is the thing:
Since you don't want to quit, one of you two guys will have to be flexible, at least at the beginning, and that is you.
Before the boss will listen to you, you first have to gain his trust. To do that, he needs to feel that you take him seriously and that you listen to his needs. Giving him that first screen will do that, so do it.
Tell him just once very strongly but shortly, with whitness or proof to support it later, that his methode will cost more money and time at long term. You can then recall this moment later when things really get out of hands. Make sure you avoid repeating it after having said it.
What's the big deal if you have to rebuild to often because of his approach? You don't want to leave, he is not listening but it's his company! You don't have a choice. Do you?
Some people only listen when they get hit. So let him feel the consequences of his methode if you're so sure that is what will happen finally. What do you care? It's his company, not yours. And if this really get bad along the way, well, you've told him, right!
If you feel you can code in such a way to limit the dammages because of his approach, do that. If it's too much work for you, leave it. One positive thing is that you'll be having a job because there is so much to do/fix. That counts too. It won't be your fault if the project takes too long, so why bother?
We, at CodeProject, we all know you've tried 
Good luck!
modified 7-Aug-14 1:32am.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
