Tuesday, March 16, 2010

I am hearing from my project management team a bit of distrust in the technical capacity of our web development team. I think we suffer because of the distance and culture but the project management team takes every late delivery or small bug as evidence that the development team may not be capable.

Great question. And the answer is that it likely takes some diving into the specific situation to understand what’s going on. And there are always multiple things that can be improved to get a better result. Still there are some common signals / symptoms that I hear about from Founders/CxOs in companies that are the reason they are calling me. I thought it might be helpful to capture these symptoms so that in the future I can point people to this. But please:

Just because your development team has these symptoms does not mean that you have a weak development team. What it means is that you likely need to dive in to figure out what you are really dealing with.

Founder Developer Gap and A, B, C Players

By the way, this question is another example of issues around the Founder Developer Gap. Developers operate at a level and in a language that others in the organization can’t necessarily interpret and understand. So, it’s often hard to know if the developer is an A, B or C player. And an “A” player is worth 10+ C players.

Also, there are a lot of C players out there. When we interview potential developers, it’s amazing to me how many can’t answer questions that every student in a sophomore level computer science course should be able to answer. I used to teach this same stuff. If a student couldn’t answer that, you normally would counsel them that they might want to think about changing majors. How did they ever graduate not knowing this stuff? And how do they have the resume they have? I often wonder what’s going on, but I don’t have time to worry about it. We try to move on to find the actual A players.

Symptoms

So what do I hear about on these calls?

Frequently missed deadlines.

Last minute scope cutting to make deadlines.

Delivery of code/product that clearly has not been tested.

Marking bugs as fixed that aren’t fixed.

Massive overtime.

No communication between developers.

No clear leader.

No one owns architecture.

Rogue developers with their own agenda.

Private bits of code that are jealously protected.

Finger pointing with no clear answer.

Fixing one thing breaks something else.

Source code control is only marginally being used.

Bugs – no big deal. The system keeps crashing – no problem.

Annoyed at testers for finding bugs.

No attention to detail.

Same problems seem to occur all the time with no desire to look at what’s behind the problem.

All new features seem to require significant rewrites and a ton of development time.

Developers can’t explain why certain changes will require more or less development time.

Developers are very quite when bugs, features, changes are being discussed and only come back with questions later.

Rest of team says - “I’m not sure where we stand.” “I’m not sure what’s in the next dev cycle or when it’s being delivered.”

And the #1 reason I get calls relates to an old software engineering adage:

The first 90% of a project takes half the time. The last 10% takes the other half.

So the most common symptom is:

The team seemed to get a lot done early on, but now it just seems like it is taking forever to get it “done.”

Again, if you are seeing a few of these symptoms, then you may have a weak development team, but it might be other things going on that make it so the team is not as effective as it should be. You need to dive in. And, of course, if you have the Founder Developer Gap, then you might want to consider getting help.

Recovery is Extremely Hard

Early failures by a development team make it really hard (next to impossible) to recover trust.

Software development is challenging. It’s often hard to know all the different questions you should have asked to get better requirements. And it’s easy to not think of edge cases. There’s pressure to get it done and get onto the next thing. Lots of opportunity to introduce bugs.

Once you’ve been labeled as someone who doesn’t produce quality work or that you are slow, it’s hard to recover from that perception because everything you do is looked at through that lens.

But this is true of pretty much any kind of knowledge work. Evaluating Performance of Concept Workers talks to how most managers lack the knowledge to be able to directly judge the performance of knowledge work. Therefore they use signals. But these are clouded by perceptions.

If your manager thinks you are not doing a good job, it’s very hard to overcome that perception and reestablish trust. A third party can help a lot in this situation.

Upon reflecting I would add a new consideration in working through the development / analysis relationship.

It is possible that expectations on both sides are not aligned and clear metrics (agreed upon by both teams) are not in place to measure success. It is very hard to assess capacities and delivery if the metrics are not consistent and are not consistently compiled.

When recruting developers I and my team like to ask them to present an example or two of their own code that addressed a particularly interesting problem, explain how they approached solution. You find out both about their communication abilities they have to explain the problem/solution, but they are talking about their own work which lowers the stress. Of course, if they can't provide any examples, or the problems/solutions are not that interesting, it tells you quite a bit.

About Me

Dr. Tony Karrer works as a part-time CTO for startups and midsize software companies - helping them get product out the door and turn around technology issues. He is considered one of the top technologists in eLearning and is known for working with numerous startups including being the original CTO for eHarmony for its first four years. Dr. Karrer taught Computer Science for eleven years. He has also worked on projects for many Fortune 500 companies including Credit
Suisse, Royal Bank of Canada, Citibank, Lexus, Microsoft, Nissan,
Universal, IBM, Hewlett-Packard, Sun Microsystems, Fidelity
Investments, Symbol Technologies and SHL Systemhouse. Dr. Karrer was
valedictorian at Loyola Marymount University, attended the University
of Southern California as a Tau Beta Pi fellow, one of the top 30
engineers in the nation, and received a M.S. and Ph.D. in Computer
Science. He is a frequent speaker at industry and academic events.