by Lorne Cooper, CEO, AccuRev

A Top 25 WordPress Blog Post of the Day 

Here at AccuRev our business requires we dive into the development process of dozens of software development organizations each month seeking our expertise. While reasons for success differ, there seems to be a pattern in ways organizations fail to deliver on their goals.

Here are seven pitfalls and tarballs to avoid when managing a software development organization.

Sin #1: Building a Weak Team

Great people build great products that generate great value. The rest of them fill up meeting rooms discussing whether they can get that bug fixed by Friday.

Sure, sooner or later someone will show you a great product developed by a committee of average engineers. Until then, do what you have to do to get great talent, and demand exceptional things from them.

Not sure if they’re good or great? Ask them to do the impossible: the good ones will tell you why they can’t do it, the bad ones won’t understand the problem, and the great ones will smile, and then ask for a little more time.

What kind of people answered (what is claimed to be) Sir Ernest Shackleton’s ad for his expedition to Antarctica?

Men Wanted: For hazardous journey. Small wages, bitter cold, long months of complete darkness, constant danger, safe return doubtful. Honour and recognition in case of success.

Sin #2: Blaming the Workers for their Bad Management

Is disaster a function of the people or the process? If great products come from great people, do failures signify you’ve hired too many chumps, and it’s time to play French Revolution with your development team? Can’t be the manager’s fault, after all, since the managers are the smart ones, or they wouldn’t have been made managers! Right?

Leadership and Management are the steering wheel and the accelerator. Development and QA are the engine. Why blame the engine for hitting the tree?

Can a project succeed despite poor management? Absolutely, and it happens all the time. Sometimes the needs are so dramatic, the architecture so obvious, and the team so experienced, that success is as certain as a Russian election.

But project failures are always the fault of management or leadership. If the engineers couldn’t do the job, good managers would swap them out, and good leaders would motivate them.

With added power comes added responsibility. Good leadership tolerates and anticipates engineering errors, but has little tolerance for management failings.

Sin #3: Short Term Thinking

If they paid you by how long it took to replace your software, you’d be a rich man, and could pay someone else to spend their time reading my blog.

When do you replace your underwear? When a new color comes out? When there’s a new innovation in cotton? If you’re an engineer, of any gender, you wait until that underwear is worn ragged.

And that’s the problem with software. It doesn’t wear out. In fact, it probably runs faster now than it did ten years ago when it was shipped. And it has more reports, more adapters, and more integrations than it did then, too. Ask any CIO: it’s hard to get rid of working software.

If you admitted your product was going to go through ten major revisions over eight years, and be used by 100,000 people, would you do anything differently? My guess is you would invest in a strong architecture, design code for re-use, and develop tons of automated tests. How about if it were to go through three revisions in two years and be used by 100 people? Same answer!

Investment in architecture is what determines whether your crack development team spends its time designing tomorrow’s skyscrapers, or on spreading spackle in the cracks in your old foundation.

Bad architecture is the answer to the question of “Where did all that money go?”

Good architecture is the answer to “How did someone so young get that job?”

Sin #4: No Investment in Code Re-Use

Good implementation recognizes that code’s going to be there for a long time, and what we build should be re-usable components. Ok, they don’t build bridges that way. But then again, the cost of building the second copy is a little higher.

If there’s one thing we can learn from the TQM experts, and even one might be optimistic, it’s that code reuse is the single most important thing you can do to improve your development organization.

If there’s one thing we can learn from experience (which might be even more ambitious, seeing how people drive in snow), it’s that Code Reuse is hard. Hard, and expensive.

Getting code that works properly is tough. It sure is nice to use something that already works. Tends to decrease the bug rate, increase development effectiveness, and best of all, gets the product to QA with fewer bugs.

Don’t forget that the amount of time it will take to get the product _out_ of QA is a function of the number of bugs it brought with it _into_ QA in the first place. An exponential function. Which, for those of you with Art History backgrounds, is a bad thing.

Code re-use is like changing the oil in your car. Slows you down, costs you money, but in the long run will save you a bundle.

Sin #5: Manual Processes

If you are going to have to do the same thing five hundred times, you’d certainly automate it. Same if you were going to have to do the same thing fifty times. How about five? With testing, the answer is yes, even if it takes ten times as long, as to do it once, you should automate it, because you’re very likely to be wrong and you will end up running the test twenty times.

This sin is pretty much the sin of “sloth” of which my grandmother used to accuse me every time she saw me pull off my shoes. Every development manager who has put on the stripes knows that good architecture code re-use, and automated testing is big. But each time we have short term project pressure, we find it hard to spend the extra time, and it’s not a little extra time; to invest in the infrastructure, streamline the functionality, expand the testing, and document the function, so we’re ready to meet tomorrow.

Part 2 conclusion