Destroying things is easy so dare to do better

It is always easier to destroy a complex system than to selectively alter it.

— Weinberg on Writing: The Fieldstone Method (page 416) by Gerald M. Weinberg

When I think of software, I immediately think of complexity. The two have been intertwined for me since I wrote my first computer program in 1971. The program I wrote was not complex, nor was the problem related to it. The linkage with complexity was evident when I realized the vastness of problems computers could solve. I remember wondering if a computer could play chess or even checkers? I immediately saw enormous potential for the future of computers, and in some ways, I think I saw my destiny.

A complex system is a system composed of many components which may interact with each other.

— Wikipedia entry for “Complex system”

I didn’t officially become a software developer until more than ten years later, but what I wondered about was already coming true. In fact, in 1996, the IBM computer program named Deep Blue defeated Chess Grandmaster and World Champion Gary Kasparov. The first time a computer had ever won a game against a reigning world champion. Kasparov came back to win the match by a score of 4-2, but in 1997 Deep Blue won the match’s last game to secure a 3.5-2.5 overall victory. Software was undeniably solving complex problems. As a result, the world was changing.

Fast forward to today. We have come a long way since someone wrote the first “Hello world.” program. The phone you carry around may have more than 1,000,000 times more memory than the 64k a good computer had in 1972. We are in the world of big data and high-speed communications, and decision-making. Our computer programs now have many different components which interact with each other. The literal definition of a complex system according to Wikipedia (and hey, it’s on the Internet, so it must be true!).

Our two quotes above seem to say software is a complex system, and it is easier to destroy complex systems than it is to make selective changes. We make selective changes to software all the time, but we don’t destroy it, right? Well, maybe yes, and maybe no. How easy is it to implement changes to the system? For most of you, making changes to an existing system is extremely difficult. You would probably agree with Weinberg that destroying it would be far easier! It is tough to make the right changes and have the changes work correctly. How often have you or your team made changes and weeks later found out that a completely different area of the system was failing because of the changes? It happens every day at companies all over the world. So what can you do about it?

The answer is amazingly simple and diabolically hard at the same time. Use better software engineering practices. The days of big design up front (BDUF) are over. It is time to learn how to create software incrementally with high quality and high value. Yes, I’m talking about Agile/Scrum/Kanban/whatever, but I’m talking about more than that too. Help your team learn about the technical practices that lead to agility, quality, and value, while not increasing technical debt. Our complex systems often have lingering technical debt issues, which make changing the software more difficult. Invest in your team (or just you!) learning about pair programming, test-driven development, behavior-driven development, refactoring, and continuous integration. Click here for an article my friend, Rob Myers, wrote about these practices.

This blog post won’t teach you any of the technical practices you need for future success. My goal is to make you aware of the techniques you need to know! Now, go do some Google searches for “eXtreme Programming,” or “agile technical practices,” and get to work creating better software for the future! It has to be more fun than beating your head against the wall wanting to destroy the software rather than enhance it!