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

Requirement 2: Business Interests Must be Aligned

There’s an old saying about the game of poker: if you look around the table and can’t figure out who’s the fish, it’s you.

Let’s face it: they’re doing it for the money. Just like you. But you’d better understand how they make money in the business relationship or you’re going to feel like you’re the only one not making out.

There are lots of companies that reward late projects and punish early ones. Not intentionally, of course. Maybe you know can recognize who this is:

When projects were late they would respond by creating special incentives, adding people to the project, and increasing the project visibility. When the project was doing well, they’d pull people off to fight other fires, take the best people away from the project leader to work on other projects, and management would stop attending the project review meetings.

Next project comes along, and the offshore project leader comes in with an optimistic schedule. You do the math.

Hey, if you’re reading this blog, you’re a smart person. You know you’re not going to change their culture, so maybe you should spend some time to learn to deal with it. Sure, people are people, and application developers in Moscow, in my experience, have more in common with application developers in New York than they do with factory workers in Minsk, but when people get in groups their behavior changes. That “group dynamic” differs depending on their cultural background.

In the US and northern Europe, senior application developers can follow a technical career ladder and get increasing career respect and satisfaction from being architects and CTOs. At least that’s the theory. In much of Asia, career status is all based on the number of people that report to you in the hierarchy. It’s an up-or-out philosophy that makes it hard for an Indian engineer to explain to his mother why after five years with the company he’s still not a manager.

When working with an outsourcing company, if you don’t figure out their model and how they get paid, it’s like playing poker blindfolded. Many companies build a model based on rotating junior people through their company on standard projects. If you need junior engineers to implement an e-commerce Web site, it’s probably something they will do many times and can do with the talent on hand. If you need people to figure out how to do something unique, your outsourcer might have all the brains in the world, but it just isn’t going to make business sense for them to put their technical leads on the project, when they could be running other e-commerce Web site apps. It makes as much sense as buying a French car or a German perfume.

One of the hardest problems in assessing professional job productivity is identifying the impact of quality. If the reward system is around requirements trace-ability and meeting schedules, quality is going to suffer. If you try to make quality a hurdle to be overcome, you’re going to spend such a long time in requirements specification you are never going to get a payback from offshoring the application development.

There are two things smart companies do to deal with this alignment dilemma:

1. Short iterations, e.g. a two-week Agile process
2. Remember Requirement #1, and bring the remote team lead back to corporate frequently to maximize alignment with the leader.

In Part 3, Don’t Annoy the Pig.

Failure teaches a man many things: don’t mix beer and tequila, dates don’t want to hear about your ex, and good software isn’t developed offshore. But success can be a better teacher, and a little failure combined with some success is best of all. After fifteen years doing projects in India, England, Israel, Canada, Moscow and the Ukraine, I’ve got the scars to prove I’ve learned a few basic requirements.

Requirement Number 1:

Leadership is everything. In case you missed it, Leadership is EVERYTHING. And I don’t mean sitting on the phone in the corporate office. I mean the person who represents everything you want to achieve and sits in that remote office having to drill the corporate mission into people who have little respect for corporate, and strongly suspect that the feeling is mutual.

The Roman Empire lasted for a thousand years, which might be longer than your project is going to last. The job with the most difficult requirements in the Roman Empire, tougher than Senator, tougher than General, was Governor of a remote province. Romans knew that the Governor had the toughest job. He had to convert his provincials into people who wanted what Rome wanted, people who would profitably grow Rome’s Empire, not people who would revolt and suck up Roman resources.

There are few application development jobs tougher than managing a remote development group. And there are precious few people that can do it. It takes great leadership, as well as management ability, which is hard to find.

Next, in Part 2, if you can’t identify the fish at the table, the fish is you.

Lorne Cooper