|
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
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
