Software Development, Coding, Forests and Trees

They say there's a forest in here somewhere

Some responses to my post “Why does software development have to be so hard?” illustrated one major (in my opinion) aspect of the problem – for many people, software development is synonymous with coding. It’s certainly understandable that someone might jump to that conclusion. After all, no matter how many slides, documents, diagrams, etc. someone produces, it is code that makes those ideas real.

Code, however, is not enough.

Over the last seventeen-plus years that I’ve been involved in software development, great strides have been made in languages and platforms. Merely look at the plumbing code needed to write a Hello World for Windows in C should you need convincing. Frameworks for application infrastructure, unit testing and acceptance testing are plentiful. Coding and coding cleanly is far, far easier and yet, people still complain about software.

While poor quality code can sink a product, excellent quality code cannot make a product. No matter how right you build a thing, the customer won’t be happy if it’s the wrong thing. The Hagia Sophia, Taj Mahal, Empire State Building, and many others are all breathtakingly magnificent structures that would utterly fail a customer who wanted (not to mention, budgeted for) a garage. We still fail to adequately understand the needs of our customers and the environments they work within. This is an area that desperately needs improvement. This is not a technical issue, but one of communication, collaboration, and organization. Neither customer nor provider can impose this improvement unilaterally.

Understanding the architecture of the problem is critical to designing and evolving the architecture of the solution, which is yet another area of need. Big Design Up Front (BDUF) assumes too much certainty and never (at least in my experience) survives contact with reality. No Design Up Front (NDUF), however, swings too far in the opposite direction and is unlikely to yield a cohesive design without far too much re-work. Striking a balance between the two is, in my opinion, key to producing an architecture that satisfies the functional and quality of service requirements of today while retaining sufficient flexibility for tomorrow.

Quality code implementing an architectural design grounded in a solid understanding of the customer’s problem space is, in my opinion, the essence of software development. Anything less than those three elements misses the mark.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.