Monday, February 24, 2014

Software Craftsmanship: The need to understand maintainability

As a professional software engineer for the last 14+ years I've gone through may iterations of what I've called myself and what I've wanted to be called. Some call us engineers, developers, programmers, web programmers, or etc. On top of those some call themselves ninjas (sigh... I hate this one with a passion), software generalists, rockstars, or etc. Earlier in my career I wanted to be called a programmer or developer. I wanted others to know that I was more than an organizer; that I actually made the software tick. As I matured and better understood what it meant to be a software engineer I started to desire to be associated closer to an engineer than a developer or programmer. Those terms no longer seemed to encompass who I was or wanted to be.

While software is an engineering discipline there's a certain art to it. The best software engineers start to recognize the patterns as building blocks. Learning how to apply prior knowledge and understanding to solve problems unseen or encountered.  As I grew and matured as an engineer I really started to feel like the software industry lacked a description for the art of software engineering.

Several years ago a co-worker turned me on to the missing piece to the puzzle; Software Craftsmanship. The software craftsmanship movement seems to fill in the gaps that are left by the description by software engineer. I am, and always will be a software engineer. But I practice software engineering as a craft. Always trying to add value as I respond to change. Always building partnerships as I collaborate with peers and customers to provided business value.

It's with craftsmanship in mind that I start on the topic of software maintainability. Why is an understanding of software maintainability important to software craftsmanship?

When we think about the software lifecycle what we're really thinking about is the total cost of software development. When I say cost I don't just mean dollar amount from the business perspective, as you may be a hobbyist software engineer and not being paid. It's just as important (arguably more important) for the hobbyist to understand the total cost of software development as it is for the professional engineer.

Regardless of what methodology you choose to implement the software development life-cycle, your life-cycle will be composed in some fashion from these parts:

  • Planning
  • Implementing
  • Maintaining

Planning involves rooting out what the software is going to or should do. I.e. what problem or problems is the software going to solve? Planning also brings clarity around who your target audience is. Understanding that target audience will give rise to helping you pick the software platform(s) best suited to reaching your target audience.

Implementing composes the tasks of designing an architecture (whether it's defined at the beginning or defined through emergent design), designing the software user interface(s) (including any API's that other engineers will consume), testing the software, developing the software, deploying the software, and creating any documentation necessary. Notice how I put testing before developing, that was on purpose.

Maintaining is comprised of everything else. Fixing bugs, implementing missed requirements or features, enhancing existing features, creating new features, removing existing features, adapting to infrastructure changes, and on and on and on. Unless your software project is killed before it's released to some sort of production use, it will spend the majority of it's life being maintained.

In the paper "Software Maintenance Costs" (via The Internet Archive) Jussi Koskinen states "The relative cost for maintaining software and managing its evolution now represents more than 90% of it’s total cost."

In the "Role of Software Readability on Software Development Cost" Emilio Collar, Jr. and Ricardo Valerdi state that "The majority of the time and effort expended during maintenance-related activities is code reading."

What this means for the software craftsman is that we should put a significant effort  into writing more readable code. The more readable our code is the higher it's quality is because it takes less effort to successfully understand and modify. When the code is more understandable it's complexity is reduced.

Writing readable code helps you and your successors spend less time maintaining code. Readable code has several benefits:
•  Cuts down the amount of time spent reading code you or, more likely, someone else has written
•  Less time reading code = less time maintaining code
•  Less time maintaining code = increased efficiency delivering products
•  Increased efficiency delivering products = reduced waste && more time writing new code
•  More time writing new code == job satisfaction!

As we invest some time in understanding software craftsmanship we'll spend some time taking a look at the tools at our disposal. There are five acronym's that are staples in the world of software craftsmanship. KISS, YAGNI, DRY, LEAN, and SOLID. We've already taken a look at LEAN, but in the coming weeks we'll take a look at the rest of these acronyms and try to see how they can help us to be better at our craft.

No comments:

Post a Comment