In software development, it's way too easy to get out of taking responsibility. Heck, how many of us are guilty of caving in to clients/bosses when they set ridiculous schedules that we know won't work? And then we go and blame the failure on crappy management. Sure, the management has/should take on a lot of blame for setting up such a dilemma for the workers but we developers certainly can't be blameless, either.
Heck, as a technical leader/manager (CTO, etc.), it's directly my *job* to fight those fights with the business folks. Alas, it's amazing to me when it's the optimism of the technical people end up feeding the insane schedules desired by the business folks. For example, it's a cliche in the industry to take the best estimates for the schedule and then triple that to get the "real" time. Why? Because idealized estimates never take into account all of the crap that comes up in reality: meetings, vacations, sick days, downed networks, meetings, updating the schedule, interviewing potential employees, etc. And they certainly don't take into account the seemingly constant "reprioritizations" of all of the work.
Now, various buzzword "methodologies" are finally giving this reality more of voice. For example, making major reprioritzations "only" happen at "iteration" boundaries. I find that particularly helpful for developers who have a long ramp-up time to get into the flow. Alas, business demands are driving more and more development into the world of the "perpetual beta" -- just launch it and they will come and we will stay in perpetual crunch mode.
So, how do you maintain your integrity and the integrity of your projects?
Its also a matter of keeping the work or not. Today the pressure is so big to provide the cost estimation some upper manager conceives as reasonable, that it is very hard not to accept. Also the job and project instability normally means that you won't get the benefits of making a good work...
I'm not stating I don't resist the above problems, I just think they are a bigger force than 10 years ago.
My company has R&D in several parts of the world. It is normal to move things from Western Europe, to some other cheaper site, such as Eastern Europe, India or China.
The project in which I'm working is comercially successful, but, the code is rotten. It isn't agile, so the traditional approach of a complete redesign was selected as the most appropriate. A concept is being drafted and the effort estimation is ongoing. In the first review of the partial effort estimation one number was given: "18 staff years is the common effort". One idea/threat was also stated: "upper management wants the effort estimation with the old [rotten] architecture" - if the effort doesn't falls to this number.
They might just continue during one more year with the old architecture, just to start in another site with totally different people. I've seen it happen with a different project I worked just two years ago. And you, the one that hold the line during one year immersed within dead rotten code will be starting a different job in a matter of months. No incentives, no nothing in the end!
I prefer to bargen my effort estimation, but, be sure that the project will be the way I want. Even if at the cost of cost overruns in the end. That's the way the industry goes today... Ah, and since in one or two years from now I'll be doing something completely different, I hope they don't start betting lives upon the software that will get out of this project.
Oh, I must say that I would prefer to evolve the project code. As a fall back I'll order Working Effectively With Legacy Code http://www.objectmentor.com/resources/bookstore/books/welc/ and give it around if the old architecture way is chosen.
Often I feel that there is a gap/misunderstanding between some higher or intermediate management and the software engeneers producing a piece of software. The managment trys to impose restrictions on the software as they deem fit, often without getting feedback from the very people who actually know if it's possible to actually implement that. Quite frankly I don't think you can seriously order someone who just told you it does take (him) at least x amount of time to produce the software or it will get fubar to do it in less time (without reducing the workload). It's like telling him he should fly. Well..he cannot.
Sure, management is higher in the decision hierachy but often they are not in the place to do a well informed decision.
I try to provide as much transparency as possible in order for the business to learn "how" to implement, even if it's at a very high level. I also try make a distinction between standard enhancements and unknowns. Unknowns are usually the ones that create the volatile time estimates. Because code usually isn't developed in a business vacuum, to me, it is imperative that the lines of communication are strong in order to deliver an appropriate solution in a defined time frame.
By giving the business keyholes into development, they usually develop more confidence in communicating with developers, and learn to isolate and manage risk. A good management team will also go a long way to suss out tasks needed towards the completion of a project.
I've found that closing the door to communication is the quickest way to failure. When a dev team says "Just give us the time, let us worry about the rest", you can pretty much guarantee the Choice of Two.
I must either be particularly bitter today, have a really crappy place to work or have just given up because I read this and had to snort. Honestly, I'm tired of taking on the the responsibility for management not being able to figure out what they want. On the one hand management wants to treat the development staff like nothing more than a bunch of interchangeable parts. On the other hand, when the shit hits the fan we all get a "pep talk" about how we're supposed to just magically make everything ok, no matter what decisions have been taken out of our hands in regards to developing the software that is, supposedly, the life blood of our business.
For you few technical people that actually have a say and get some respect, God bless you and keep fighting the good fight. The rest of us, I think, need to go start our own businesses and simply crush the idiots we currently work for.
> I must either be particularly bitter today, have a really > crappy place to work or have just given up because I read > this and had to snort. Honestly, I'm tired of taking on > the the responsibility for management not being able to > figure out what they want. On the one hand management > wants to treat the development staff like nothing more > than a bunch of interchangeable parts. On the other hand, > when the shit hits the fan we all get a "pep talk" about > how we're supposed to just magically make everything ok, > no matter what decisions have been taken out of our hands > in regards to developing the software that is, supposedly, > the life blood of our business.
I have an added irritant of 'senior technical' people who have clearly buzzworded thier way up the ladder. I am told to consult with them to hear words of wisdom like "authentication is dangerous" (really? what's your solution? don't authenticate?) I am also told to use their tools which invariably don't meet our needs and after explaining in depth how I am not 'doing the wrong thing' and showing how the tool could be improved (simply even) the conversation ends abruptly. In any event I feel your pain.
In any event, I thought the article was great and I think there was something in it that was sort of understated. It's not just the engineer that did the right thing, the management had the courage to not chop his hands off. By accepting this mistake it made it clear that honesty was more important than being preceived to never make a mistake. I really don't see a lot of that where I work.
> Its also a matter of keeping the work or not. Today the > pressure is so big to provide the cost estimation some > upper manager conceives as reasonable, that it is very > hard not to accept. Also the job and project instability > normally means that you won't get the benefits of making a > good work...
So, is it just that you're afraid of losing your job or is there something else going on?
> So, is it just that you're afraid of losing your job or is > there something else going on?
How can people say "just that you're afraid of losing your job"? Our company just had 25% of its staff cut after being bought out for the second time in 3 years. I'm still here, but try losing your job and then put the word "just" in front of that statement.
Maybe you can afford to "just" lose your job. I don't think most of us can.
> Often I feel that there is a gap/misunderstanding between > some higher or intermediate management and the software > engeneers producing a piece of software.
Is this "just" a (lack of) communication issue?
> The managment trys to impose restrictions on the software > as they deem fit, often without getting feedback from the > very people who actually know if it's possible to actually > implement that.
I.e., have we developers taught management to distrust what we say because our own estimates are so full of crap? Or is it that managers are clueless wackos? Or both?
Or, is it that the construction of the software development game such that we are all more or less trying to do a reasonable job but the forces, constraints, pressures, incentives, risks, etc. conspire to induce us to do poorly?
> > So, is it just that you're afraid of losing your job or is > > there something else going on? > > How can people say "just that you're afraid of losing your > job"? Our company just had 25% of its staff cut after > being bought out for the second time in 3 years. I'm still > here, but try losing your job and then put the word "just" > in front of that statement.
Been there, done that, have the debts to prove it. :-) :-(
> Maybe you can afford to "just" lose your job. I don't > think most of us can.
Ah, so, for many people, it is fear and the attendant aversion to the negative consequence which dominates the desire for integrity, quality, etc.
So, if fear is the fundamental issue, what can we do about it? Or do you think that we're just doomed to be stuck in this hell forever?
"If you haven't been fired often enough then you're not doing your job." --JDM
> I.e., have we developers taught management to distrust > what we say because our own estimates are so full of crap? > Or is it that managers are clueless wackos? Or both?
I think a lot of the problems come from the dot com bubble. There was a dearth of talent and mobs of charismatic charlatans in IT. We still carry the load of imcompetent people and the charlatans, though reduced in number, have left a indellible stain on our industry.
Part of the problem is that the average upper management type has the computer skills of my 99 year old grandmother (well, maybe that's an exageration but you get the point.) They are completely unable to distinguish skilled technical minds from skilled bullshitters. I think a lot of them figure they have no real way to ensure success on their own so they might as well go as cheap as possible.
> I try to provide as much transparency as possible in order > for the business to learn "how" to implement, even if it's > at a very high level. I also try make a distinction > between standard enhancements and unknowns. Unknowns are > usually the ones that create the volatile time estimates. > Because code usually isn't developed in a business > s vacuum, to me, it is imperative that the lines of > communication are strong in order to deliver an > appropriate solution in a defined time frame.
So are you talking about the traditional managerial tools like gantt charts and reports or things like the agile communication tools? I.e., how do you go about providing this transparency in a way that management understands and can make "good" decisions?
In my experience the realistic estimate is not acceptable. We are continually pushed to cut corners. My most painful experience of this was dropping in a consultant written module into our product as is. I did the best I could with the two or so weeks I was given to work on it. To do it correctly would have taken about 12 - 13 weeks. Every day for two and a half years now I have paid for that decision made by management. I did everything I could to let people know that this was a REALLY BAD IDEA.
I honestly don't know what the problem is. I think trying to pin down one grand cause for this problem is doomed to failure. There are such a myriad of forces applying pressure to get things done as fast, or faster, than possible that we are doomed to release garbage. In my past 6+ years at my current company the parts of the application we have been allowed to design and implement in a reasonable way have been much, much less problematic than those that are slapped together with spit and tape. There are several modules I know very well because I'm in them almost daily. These are the problematic ones.
There are others that I have to look at maybe twice a year at most that cause me to have to go through all the code and documentation we have on it because I don't look at them too often. Why don't I look at them too often do you ask? BECAUSE THEY JUST WORK!!
I would think that my view on this is really, really skewed except for the fact that several other developers on my team have the same exact experience.
I can only speak for myself but I have always given the best estimates I could. They are usually reasonably accurate, within one or two weeks of when I initially propose and more often than not they are off because I get dragged into supporting some big client or sale that just has to have something done. I'm in the middle of one such episode right now, actually.
My one big question about this great search for the underlying cause of systemic issues is, if we find the answer, will it really change anything? I think we've known the answer for more than three decades now. Still we don't acknowledge the simple fact that designing large robust software systems is a very arduous task that takes a lot of time and a lot of talent. All this other soul searching and focusing on process over talent is a smoke and mirros show to divert us from that simple truth. As long as there is a search for some underlying "trust" issue or process that can be tweaked we can conveniently ignore this fact, pay developers less than what they are worth, blame them when things out of their control go wrong and all in all continually dump on them for the simple reason that they'll take it.
Flat View: This topic has 29 replies
on 2 pages
[
12
|
»
]
Previous Topic
