6 things I’ve learned about software development

Comments (1)

Print This Post Print This Post

Email This Post Email This Post


Hi. My name is Bernie Thompson. I’m one of your occasional tour guides here at our library of the latest lean thinking.

I’ve managed teams and done development on some pretty huge projects (OS/2 and Windows OS development teams), been on the periphery of large-scale open source development, and played the jack of all trades in startups. It’s a good sampling of the spectrum of environments for writing software. Today, you can find me at leancode.

In every project, people come to the table with many different conceptions and expectations — sometimes wise but often naive. We always seem to be re-learning how challenging large-scale creative engineering projects are. I certainly have.

A few years ago, I had the chance work with a great group of people in Microsoft’s internal process improvement group, including working with a guy named Corey Ladas, our co-conspirator for this blog.

Microsoft is an amazing, massive petri dish of development practices. We had the wonderful opportunity to teach and consult with many of these teams. Microsoft has whole orgs doing TSP, even more orgs doing variations on Scrum. But most orgs — especially the large ones — are doing their own thing, often reminiscent of what you’ll read in Microsoft Secrets or the recommended practices of Rapid Development. I had the chance to take all that experimentation, tie it back to theory, and test it in class each day.

So here are 6 things I’ve learned about large-scale creative engineering (of which software development is a type):

  1. Creative engineering is a knowledge creation process. It’s mostly a research activity, sometimes a design activity, never a production activity. The cone of uncertainty is an essential concept. Risk is everywhere.
  2. Lean thinking, applied to software development, can do amazing things to attack risk — in doing so, increase your output and decrease stress on your people
  3. People are primary. Processes and tools are important, but they must “first, do no harm”.
  4. Every person, team, and project is different. Teams and individuals at every level must be empowered and self-directed to be their best. We must resist the instinct to command and control.
  5. To be effectively self-directed, teams need regular feedback, time for reflection, and permission to adapt to their unique circumstances.
  6. To facilitate adaptation, yet avoid miscommunication — it helps for teams to leverage a common toolbox of practices and techniques.

I hope you find our toolbox interesting and useful. We stand on the shoulders of giants.