Fog Creek Software
Discussion Board

old dog, new trick?

I work for a software development company that is rather set in its bad habits.  Our company development process has some major problems.  To name a few,  we have little to no unit testing, poor functional spec'ing, a huge archaic legacy code base, and the culture is very resistant to change.

I have tried to invoke change within my personal department with varying levels of success.  For example, we started unit testing using junit.  However, due to the nature of our applications, there needs to be a decent amount of work put forth to build a framework for unit testing our applications... otherwise we end up just duplicating our efforts.

This kind of decision needs to be driven down by upper management, but our management is driven solely by development that generates realizable revenue.  If it doesn't have revenue associated with it, it is not worth doing. 

Even cleaning house and refactoring our existing code base (which greatly needs it) is not an option.  As a result, we have a growing mass of code that is becoming increasingly more difficult to maintain.

Now, I have tried my best to make lemonade out of these lemons, but I am beginning to feel that if upper management does not buy into the necessity for these changes, then I am just wasting my time.

Have any of you been in this situation and found a good way out of it (other than the obvious :) )?


Some Developer
Monday, December 23, 2002

Well, the way that I've seen work is to, with your better development strategies, make sure that you are measurably less buggy, more timely, and cheaper.

That's the only way to be sure that your upper management will buy in.

Monday, December 23, 2002

"This kind of decision needs to be driven down by upper management, but our management is driven solely by development that generates realizable revenue.  If it doesn't have revenue associated with it, it is not worth doing."

Sounds to me like a very intelligent upper management team. 

Joe AA
Monday, December 23, 2002

Not sure whether JoeAA is being facetious or not, but of course, any intelligent management is going to nix things that don't maximize revenue (assuming a direct relationship between revenue and profits).  Duh. 

The trick would be to enlighten them and show them that unit testing and other things, over the long term, will increase revenue.  If they agree that these practices will increase revenue over the long term, but nonetheless decide against them in an attempt to maximize short term revenue and profits, then they're idiots.  But maximizing revenue/profit  is practically the sole purpose management has in life.  You can't fault them for that.  Only for doing it poorly (e.g., concentrating on short-term at expense of long-term).

Martin Fowler has a section in his book, "Refactoring", where he gives advice on how to get a development group to accept refactoring even though it appears on its face to slow things down.  Might be worth taking a look at what he had to say there.  I think basically everything he says can be framed as an argument that refactoring (and also unit testing) is a way to maximize profit over the long-term.  That's the only reason a business should do it, in my opinion.

Herbert Sitz
Monday, December 23, 2002

Yes, I dont think it's carte blanche that unit testing is a good thing.

It has to have good end results, often the overhead of unit testing effectively kills its benefits.

Monday, December 23, 2002

"any intelligent management is going to nix things that don't maximize revenue"

Agreed, this is exactly the reason why it is so very critical to pay the CEO $131 million. Because it contributes directly to the bottom line. All else is fluff. Any intelligent management recognizes the importance of high pay for upper management. Because if you want to attract the best management talent, it goes with out saying you have to pay the best compensation. Software on the other hand is a different matter entirely. It all works the same so there is no need to pay a premium. Just outsource it to people you have never met. It's no different than outsourcing paper towels or handsoap. One is much like the other.

Ed the Millwright
Monday, December 23, 2002

Well, there's no question that there are some really wacky examples of executive compensation out there.  But that doesn't show that maximizing profits is not what management is supposed to do.  It just goes to show that some many not be very good at doing it, and we all already know that.

My impression is that though there may be a big problem with out-of-control executive compensation, it's not as bad as the mainstream media makes it sound.  For example, please tell me how many CEO's made $131 million?  You can get a few facts and figures on CEO compensation at this site:

That data shows, for example, that the average CEO compensation at the largest companies (i.e., revenue over $1 billion) was $1.4 million dollars in salary and bonus, and $5.6 million value in stock options.  Too much?  Probably.  But a far cry from the outrageous numbers that get all the publicity.  And these are BIG companies.  Even if I could, there's no way I'd want to be a CEO of one of these companies.  Entirely takes over you life.  No way I'd do it, not even for that kind of money.


Herbert Sitz
Tuesday, December 24, 2002

You should opt to be paid hourly.  The inefficiencies become more tolerable when your pay increases as a direct result of bad mgmt decisions.

Tuesday, December 24, 2002

I'm in this situation at the moment.

I am managing a whole load of code written by amateurs which was never reviewed or mentored. The manager knows the code is bad; why didn't he find out sooner to try and avert disaster? I don't know.

It is true that no manager will ever action work that has no financial gain - the real question is how far past the end of their nose can they see? We're now almost getting to the state where customers are throwing our products in the bin and our dealers are refusing to handle the products anymore - did it really have to get that far to work out that code reviews, testing and writing documentation were only time savers in the short term?

As mentioned above, the best thing you can do is pursue good development practices as far as they can go. I do daily builds of my project on my PC, log all bugs, write design documents where necessary, and I've had a stab at writing a spec (which hasn't been too successful as it contains some "controversial" things that I know aren't implemented but have been sold as such anyway).

I think eventually, though, if upper management does not buy in then you should just quit. Do bear in mind that if you mention you've tried to follow good practices in the face of indifference in an interview, it will count in your favour, as it will tell the interviewer you strive to get things done properly.

Best of luck.

Better than being unemployed....
Tuesday, December 24, 2002

Like others have said, showing that the returns in the long run will outweigh the short run benefits is the way to go.  Now you just have to prove that hypothesis (yes, it's a hypothesis until you prove it -- which means you could be wrong or you could be right).  Of course, your gut feeling is that you're right, while managment's feeling is that you're wrong.  The onus of the burden of proof is therefore on you if you want change to take place.

One means of going about trying to prove your conjecture is by researching data and finding case studies which *quantifies* the before and after pictures.  I.e. on average before the code cleanup/reviews, etc. it took around 2 hrs to fix a bug.  After the code cleanup/reviews, etc. it then took only 1 hr to make a change, fix a bug, or add a feature.  You would then take the time savings and multiply it by the average number of bug fixes, feature additions, etc. to come up with the time saved per year.  Multiply that by an average hourly rate to get the amount of money saved.

Then you have to figure out how much it's going to cost to implement those changes.  Obviously, it's going to take more time to develop a feature when you also have to document, write unit tests, do code reviews, etc.  Figure out how much extra time and find out how much it will cost over a year in a manner similar to how we figured out the costs above.  You'll probably also want to factor in the probability that releases will be much later and problems might not get fixed faster as a result of the extra overhead in implementing these new processes.

Finally, just subtract the two values.  Savings (when implemented) - Cost (of implementation).  The value should be positive, and be a large amount.  If it's only around $500-$1000 in savings after cost is subtracted then it may not be worthwhile to do so -- from management's perspective.

The main thing to get out of this is that to objectively persuade people you have to show the numbers.  Another way to get managment to change is to play corporate politics but that's another whole can of worms altogether -- but it might get you what you want easier if you're not too good with research, numbers, and estimation.

Good luck!

Wednesday, December 25, 2002

Buy authority or bring in a friend.  That's the easiest way to effect change in most political situations, not just in the IT world.  Bringing in someone loyal worked for me.

As long as you have the framework working, you've gotten past most of the inertia.  The rest can be small changes.  When working on a new feature, spend a couple extra hours generalizing something.  Then when you pass other code that could use it, change them too.

Wednesday, December 25, 2002

*  Recent Topics

*  Fog Creek Home