How can I persuade the boss to do things differently? (VERY LONG WHINGE)
-
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
D*mn I don't know who you are, but clearly we work in the same company. Only difference is that my requirements come from one division and my tools come from a different division. The two divisions don't talk with one another and generally disagree. My job is 'easy' all I have to do is write code that makes it 'pretty', keep the customers happy, mates two contridictory goals, and attend meetings where we ... um ... we ... well ... um ... anyway attend meetings. :-)
-
Maxxx_ wrote:
What he actually said was "The service will run on the server". What he (apparently) meant to say was "The server will run on the client".
My team leaders favourite sayings are: - Generate the code - ... or something Either or both occurs every 5 minutes during conversation.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 beta 2 - out now!
((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))leppie wrote:
- ... or something
I'll be damned. I didn't realize my teenage daughter was your team leader. That can work to your advantage. "Do blah blah blah or something." Then you can do whatever you want. "I chose 'or something.'" ;P
BDF People don't mind being mean; but they never want to be ridiculous. -- Moliere
-
leppie wrote:
- ... or something
I'll be damned. I didn't realize my teenage daughter was your team leader. That can work to your advantage. "Do blah blah blah or something." Then you can do whatever you want. "I chose 'or something.'" ;P
BDF People don't mind being mean; but they never want to be ridiculous. -- Moliere
Big Daddy Farang wrote:
"Do blah blah blah or something." Then you can do whatever you want. "I chose 'or something.'"
:) Almost sounds like Trainspotting; I chose not to do blah blah, I chose 'or something'!
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 beta 2 - out now!
((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x)) -
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
I think this is a great topic that persists a feeling in IT in general. Probably someday there will be a degree or course in Engineering Psychology or the Psychology of Design as it pertains to building consensus with COMPLETELY disparate groups. 1) A good salary is a great thing, but that $ doesn't reduce frustration. If your any good at your job you're passionate, then salary is a ends to a means, ie we normally want to build something and look back on that and say, "I did that". 2) Although he is an MD, and therefore Omnipotent, he has had to have a peer review from time-to-time. See if you can find an instance where he was doing something one way and had to reconsider. Especially in medicine where there aren't "do-overs". This will help bring to him the idea that even though this is software and your time is infinite :-) it would be best to have a "plan" going into it like a treatment plan or surgery plan. 3) Detachment from outcome is a wonderful thing but hard to obtain. If you would rather do then redo, it might be time to move on. If you can look at this is a challenge that you're obviously taken on, consciously or subconsciously, then it would behoove you to stay the course. Build the system the way you think it should work and then show it to him. But remember if you make someone feel like a dipshit, even if they deserve it, then you'll probably fail and loose the game. Even then you can say you played a good game but we all would rather win then say we played hard. Happy Hunting :)
We all sit around and suppose while the secret sits in the center and knows - Robert Frost
-
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
Recognize that your frustration (and probably the boss's) stem from different ways of working. He is not organized, but develops his ideas in "real time". Many successful people have short attention spans, it's not wrong just different from your approach. You shouldn't try to change that, but should figure out how to best work with it with a minimum of frustration to both of you. Seems like you need a quick prototyping system that shows the GUI and a very limited interactivity. That would allow you to iterate the front end and functionality until he is satisfied w/o investing time in a framework. Once the frontend is completed you can build the backend.
Melting Away www.innovative--concepts.com
-
Recognize that your frustration (and probably the boss's) stem from different ways of working. He is not organized, but develops his ideas in "real time". Many successful people have short attention spans, it's not wrong just different from your approach. You shouldn't try to change that, but should figure out how to best work with it with a minimum of frustration to both of you. Seems like you need a quick prototyping system that shows the GUI and a very limited interactivity. That would allow you to iterate the front end and functionality until he is satisfied w/o investing time in a framework. Once the frontend is completed you can build the backend.
Melting Away www.innovative--concepts.com
Member 4723455 wrote:
different ways of working.
You can say that again!
Member 4723455 wrote:
quick prototyping system that shows the GUI
I actually set one up specifically so he could do this - but he thinks it's a waste of time because we then have to do the GUI twice - once for the prototype and once for real - and if he doesn't use the exact controls, it might look slightly different. As it is we probably change each user control about 20 times before it gets to what he wants - and probably 20% of thos changes involve changes to the business logic and/or object model
___________________________________________ .\\axxx (That's an 'M')
-
D*mn I don't know who you are, but clearly we work in the same company. Only difference is that my requirements come from one division and my tools come from a different division. The two divisions don't talk with one another and generally disagree. My job is 'easy' all I have to do is write code that makes it 'pretty', keep the customers happy, mates two contridictory goals, and attend meetings where we ... um ... we ... well ... um ... anyway attend meetings. :-)
grgran wrote:
but clearly we work in the same company.
OMG - you had me worried for a minute!
grgran wrote:
and attend meetings where we ... um ... we ... well ... um ...
We have those meetings too. Foolishly(?) I suggested we actually have some sort of agenda for a meeting, and stick to it - and also suggested that, if a meeting was to decide whether to use this control or that control for the display of lists, we actually make a decision during the meeting, rather than saying "That's a technical issue" and leaving it at that. I have not been invited to any more meetings. WIN!
___________________________________________ .\\axxx (That's an 'M')
-
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
Dude! I feel ya pain brutha!! The rant you posted could've not come at a better time. I was just lamenting to my soon-to-be spouse about the sorry state of affairs on my development team. It's as if we are working for the same boss! There have been some good replies to your original post. I think my approach going forward will be to continue to make good suggestions (and document that the suggestions have been made), but in the end obey my boss's commands. One way I can make suggestions is in the context of doing what's best for the team, and hopefully help her see the light in that manner. Obviously I can't go to her and tell her that she is the sorriest development manager I have ever worked for or she might take that personally :-) My best bet is to keep it impersonal and in the context of doing what's best for the company, the team, and ultimately her. Leaving the company is not an option for me because I love it too much. For now I'll just have to suck it up. If things do not improve over time as I build trust with her, then eventually I will have to raise my concerns up a level (i.e. to the boss's boss). Politically this is risky, but I have good relationships with leaders who are higher up the food chain than she is. My boss is politically savvy and knows how to cover her tracks to keep people appeased, but I think eventually it will catch up to her and she will be replaced.
-
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
There is a lot of good advice here from people that have clearly been in your situation. I too wasted a year of my life trying to make a difference in a situation very very similar to what you describe. (Right down to the "buy out"...). You can't win - you can temporarily lose your sanity. From the nature of your post, I can tell you feel like no-one else could possibly have experienced what you see every day, I too thought this, but it just isn't so. You can learn a very valuable lesson though - worry about your own reaction to the situation. Control what you can control and leave alone (or learn to co-exist with) what you cannot not - otherwise it will eat you up. Geez, listen to me...I'm preaching a bit too much now, it's not like I handled my own situation that well.. Anyway, grab yourself a copy of Stephen Covey's "Seven Habits of Highly Effective People" - it's perfect for this situation.
Stu
-
The MD previously ran a company that developed similar software to what we are developing. That company was 'successful' in that it was bought by another company, giving him enough money for a while. With this new company, there is an appalling lack of any design whatsoever. The process of developing the software package is: The MD designs some user controls USING THE LIVE SOURCE. Just GUI no code. Sort of like prototyping if it was done by a duck. He commits to SVN then tells someone to develop it. No other details unless you ask - so it can take a while to get information about it (like what does that button do - will there be a list of these or a single one, is it updatable etc. etc. and quite often he hasn't thought enough about it to answer) When something has be developed, he'll take a look, then change his mind about what he wants, and get it to be redeveloped. If he is asked to spend some time designing it before putting mouse to screen, his response is always "I can't give you 100% of what we need, because things will change" and "I know you want to do things differently, but I have developed successful software before, so I won't waste time specifying things unnecessarily." I tried to develop a framework for the latest part of the development, after several meetings being able to decide approximately what he wanted. Now he wants to develop new user controls within the framework - but he's brought in new requirements that, at worst, break the framework, and at best compromise the design (i.e. had I known about these requirements, the framework would be different). So, I asked that he define these requirements, then I could modify the framework to suit, then he could do the GUI design. Nope - he "can't work like that". So - he's designing using a framework that won't support the requirements. If he would finish the design before wanting me to start developing, at least I could modify the framework once I know what it needs to support -but he wants me to start now - with only one or two parts designed. As a real example: On the left is a list of some 20 link labels. Click on one and to the right a User control will be instantiated, containing a list of items. Select an item from the list and another user control will be instantiated showing the details of the selected item. The framework was designed to support this. Now three of the options don't show a list but show an editable view, and at least two (possible more, he hasn't thought it through yet) will show one of two diffe
Why not just do what he pays you to do. If he doesn't pay you enough, it's a different issue entirely. Sure, it might not be fun to rewrite code over and over again because of his whims, but if you're being paid for it, so what? Apparently he thinks he is paying you to follow his orders and just write code -- not to actually work with him to develop software. He wants to develop; he wants you to code. I have been in the same place before. I am now, actually. The bottom line is, its not your problem if the software sucks, and it's not your fault, either. You've done your duty by voicing your concerns, and he's dismissed them. As long as this software isn't used in a critical application where it would be unethical to accept these kind of flaws, it's not a big deal. I know that's not what you want to hear, but this guy is a jack-off who wants to play developer, but doesn't know how. You've gotten suckered into playing along with him. But he's got the cash, so you either play, or you tell him to screw himself and move on. It's really up to you. If the money is good, just do whatever he asks and STOP CARING about the software. It's clear that he's the developer here, not you. He's just paying you to write some code. Of course, depending on the situation you might be able to get some small concessions by exaggeration the limitations you're working with. Answers like, "that's not possible" or even "I don't know how to work like this"
-
Why not just do what he pays you to do. If he doesn't pay you enough, it's a different issue entirely. Sure, it might not be fun to rewrite code over and over again because of his whims, but if you're being paid for it, so what? Apparently he thinks he is paying you to follow his orders and just write code -- not to actually work with him to develop software. He wants to develop; he wants you to code. I have been in the same place before. I am now, actually. The bottom line is, its not your problem if the software sucks, and it's not your fault, either. You've done your duty by voicing your concerns, and he's dismissed them. As long as this software isn't used in a critical application where it would be unethical to accept these kind of flaws, it's not a big deal. I know that's not what you want to hear, but this guy is a jack-off who wants to play developer, but doesn't know how. You've gotten suckered into playing along with him. But he's got the cash, so you either play, or you tell him to screw himself and move on. It's really up to you. If the money is good, just do whatever he asks and STOP CARING about the software. It's clear that he's the developer here, not you. He's just paying you to write some code. Of course, depending on the situation you might be able to get some small concessions by exaggeration the limitations you're working with. Answers like, "that's not possible" or even "I don't know how to work like this"
Arterion wrote:
its not your problem if the software sucks, and it's not your fault, either.
Short sighted view IMHO. If it doesn't work you can bet your cahoonas that the MD won't be taking the flak - he'll be blaming the developers. Also, imagine the next job - "I see you worked at xyz before -they went toes up because the software was shite didn't they?" NOt exactly where you want to be !
Arterion wrote:
As long as this software isn't used in a critical application where it would be unethical to accept these kind of flaws,
Actually, it is.
Arterion wrote:
If the money is good, just do whatever he asks and STOP CARING about the software.
unfortunately I have standards, and don't whore myself when I can avoid it. Getting another job at the moment is not quite so easy.
___________________________________________ .\\axxx (That's an 'M')
-
There is a lot of good advice here from people that have clearly been in your situation. I too wasted a year of my life trying to make a difference in a situation very very similar to what you describe. (Right down to the "buy out"...). You can't win - you can temporarily lose your sanity. From the nature of your post, I can tell you feel like no-one else could possibly have experienced what you see every day, I too thought this, but it just isn't so. You can learn a very valuable lesson though - worry about your own reaction to the situation. Control what you can control and leave alone (or learn to co-exist with) what you cannot not - otherwise it will eat you up. Geez, listen to me...I'm preaching a bit too much now, it's not like I handled my own situation that well.. Anyway, grab yourself a copy of Stephen Covey's "Seven Habits of Highly Effective People" - it's perfect for this situation.
Stu
-
Thanks!
SHelwig wrote:
Seven Habits of Highly Effective People
Is that the 'hats' book?
___________________________________________ .\\axxx (That's an 'M')
'Hats book? - not sure. Here it is on Amazon Also on Wikipedia. Habit #1 - Gold!
Stu