|
Well, the obvious thing to me is that the UI mockup won't be addressing edge cases - there's an education process that needs to be done here, so start off by working out what a couple of the edge cases are and asking how they would be addressed. One of the things I would address with him is the fact that a wrong design decision now will end up costing a lot more further down the line, and the processes you are following are designed to save him pain and money in the longer term.
As we don't know what the business is, we can't offer much in the way of advice - but there's probably something analogous in his business that he has to approach properly otherwise it will go "belly up" for him. In other words, relating things to him in a way that's familiar will make it much easier to sell it to him.
|
|
|
|
|
Thanks -- good food for thought. Teach and train. I see a lot of deep breaths ahead, but seeing this thing work will be very rewarding.
I like your suggestion about finding ways to relate to him. We are such completely different people... That's going to be tricky.
|
|
|
|
|
I regularly go through exercises like this with my clients. It's frustrating at first, but ultimately it's rewarding.
|
|
|
|
|
One of those edge cases must be mobile computing - can't put very much on a mobile screen before it starts looking pained...?
|
|
|
|
|
Agreed. That is on the list :/
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
