“You might not think that programmers are artists, but programming is an extremely creative profession. It’s logic-based creativity.” — John Romero
When we think of software engineers, we envision people with highly technical minds. We may go on to assume that these people did great in math and science courses. We tend to draw these conclusions because we’ve been conditioned to think of software development as a purely technical task. This is not the case, however, and I would even go as far as stating that the development of software is mostly an artistic craft with some highly technical elements sprinkled in.
A successful software product is not engineered once, deployed and forgotten. Rather, it is the result of an ongoing creative process, with its goalposts continually getting pushed further and further away. Every new requirement, experience or technology helps reshape what is considered to be the “final product.” I find that, all too often, many organizations fail to recognize the creativity involved in developing software products. This failure can lead to missed opportunities, curtailed innovation and losing the edge in an increasingly competitive landscape.
The shift away from thinking of programming as an art rather than pure technology did not happen overnight. Think about all of the common terms borrowed from manufacturing that are typically applied to software engineering: builds, architecture, development, defects and even engineering. We’ve even done this in academia when referring to disciplines such as computer science. Don’t get me wrong — I’m not implying that there is nothing scientific or technical about developing software. However, emphasizing only the technical aspects of software development forces it to abide by a strict set of rules that are sometimes not applicable. Building software, unlike shipbuilding, is typically a chaotic and unpredictable mess with no predefined intentional design.
The software development life cycle tends to resist the traditional rules that govern other forms of engineering. That disconnect can manifest itself in several ways within your organization.
• Did you intend to adopt some agile methodology, only to end up with some modified version of it?
• When was the last time a developer gave a straight answer to the question, “How long will that take?”
• Are your estimations in complexity and timelines inconsistent?
A creative process requires two modes of thinking to be successful: divergence and convergence. During divergent thinking, the process is chaotic and indeterministic. This part of the process cannot be restrained; it will always find a way to break rules and cut through red tape. It is where innovation thrives and programmers think broadly about the problems they are trying to solve. This is the state of mind that most people associate with artistry. Convergence, on the other hand, is probably more closely associated with traditional engineering. During this part of the creative process, engineers refine the broad set of ideas that divergent thinking generated down to a small batch and prepare them for development.
Divergence and convergence are familiar jargon for those in creative groups. Nonetheless, I’d like to introduce an additional part of the process for software development: reflection. Reflection is the process of sitting back and taking a good look at the result of the convergence phase. This is the time to make a note of the things that did or didn’t work well. Consider this a retrospective within the creative process.
It’s important to note that this is not a one-time endeavor. As mentioned earlier, this is an ongoing process that cycles through the many different stages of a software product’s life. Every iteration encourages new ideas inspired by the experiences of the previous iteration, thus refining the product to better meet current business demands and provide future opportunities. The ultimate goal of each iteration is an intentionally designed software architecture.
Intentional architecture is a planned set of decisions that result in optimal solutions for performance, scalability, usability and integration. Think of this as a finalized work of art. It may look like something with purpose and meaning now, but it was just a set of roughly drawn lines when it started. The difference is that the developer has to cope with a changing audience, an evolving set of tools and an ever-expanding canvas. This is why restarting the creative process is so important.
Embracing the creative origins of software development can yield tremendous benefits for your product and your organization. Starting to leverage this process can be surprisingly simple: Just make time for it. If you’re about to start working on a milestone for your product, make sure your team is aligned with the divergence stage. If you’re at the end of a milestone, carefully reflect on the decisions you’ve made. If you’re somewhere in the middle, choose the part of the process that is most appropriate. It may be early enough to get in an innovative, divergent mindset. If you’re focused on implementation, then you’re right in the middle of the convergence stage. The best thing to do in this case is to look for an opportunity to reflect and start the divergence phase.