Source Code: An Important, Yet Undervalued Asset

February 22, 2011

Non-developers in many organizations tend to believe that software developers have too much concern about their own universe of source code and tools and too little concern about the business. A majority of the developers that I’ve worked with genuinely care about the business. The fact that they care about the source code is a good thing. The business should care more about it, too.

Software tends to live, sometimes a lot longer than we expect. I’ve written code in years past that I believed would be made obsolete by a rewrite a lot sooner than what actually came to pass. In fact, I’ll confess to being a little frightened with the longevity of some of my code.

Code that lives a long life does so for many reasons. One of which is that the code is satisfying an ongoing need. However, long-lived code does not begin life in a mature form. It has survived multiple versions, and with those versions came enhancements.

This is obviously a highly desirable scenario: You build something that others want, and they request new features to be added (along with demanding that defects be fixed). Software companies make a great living continually reselling an existing asset, incrementally adding to it to drive even more revenue.

Software development cannot focus exclusively on the end result – such as the number of features delivered – because it possible that like Icarus, soaring too high into the sky with improper equipment will cause you to crash back into the Earth. Sustained flight in the form of a long-term stream of profits from delighted customers is what we want. And to achieve that we need correct execution.

Correct software execution is reflected in two places: a feature set that delights the customers and the source code that makes those features possible. Well-designed software contains fewer defects than poorly designed software and it can be maintained over time. This allows new features to be added with less time and effort than possible with poorly designed code.

Well-designed software is the product of your people, their abilities, and the extent to which they have been permitted to maintain the source code. Many organizations try to react to immediate needs and short-change the process, believing that they can defer activities like refactoring to later. This thinking surfaces as something like, “Customer XYZ is important to us, and we need to get this feature in NOW!” Deferring work like refactoring creates a debt that must be paid later, and the reality is that paying with today’s dollars is cheaper than what it will cost you tomorrow.

How much investment are you making in your people? To what extent are they provided the means to truly build their skills? Project schedules that expect constant overtime don’t provide opportunities or the motivation to enhance skills. If taking a few days of training means even greater work and overtime is waiting in the wings, people will elect to defer on training; unless they take the training with the intent of getting another job someplace else and put that work behind them…

Too little investment in building and keeping the skills current of the very people responsible for creating and maintaining the key asset(s) of your organization is reckless. People with poor or outdated skills will not produce software that can be considered an asset. It will become a liability, even if the initial indicators are that the concepts represented in the source code have value.

Poorly designed software that meets a legitimate business need can place you on a roller coaster. Things are great early on as customers snap up your software, and early in the cycle features can be added in reasonable time frames, until…

You can’t. At least not within budgetary and scheduling time frames that are acceptable. And it won’t happen all at once, it will sneak up on you. You will gradually encounter problems with estimates as the time it takes to implement new features increases and quality problems begin to surface. Every time someone works in the code, two or three other things break.

If you’re lucky you will have time to do something about this, like undertaking an expensive rewrite. It is also possible that the product or even an entire organization will sink under the weight of poor design. Imagine the pain of failing because of poorly-designed code in the face of strong market acceptance of your software! It can happen.

You can take steps to avoid this scenario. Talk openly and honestly with your developers about tools and techniques to assess code maintainability and make this a focus of your attention. The features used by your customers are delivered by the developers working through the source code. This makes your source code a critical asset. Give it the attention that is is due!


Erx said...

No comments on such a great article? keep up the good blogging, and i have come to a point, or encountered this same problem as we speak.

back when i started my VB6.0 application 13-14 years ago, and am still developing as we speak, there was no TDD to speak of, i hadn't even heard of the term.

Now, i've come to a point where complexity has gone very high, and lack the confidence to make incremental changes in fear that it may break something else, somewhere else in the application.

This is really dragging on my productivity like you could not imagine, probably writing code up to 10 times slower in _some_ cases.

If I had tests, I could just re-run the tests after every change.

If I had tests, I could have migrated the application to by now without worrying as much about migration issues - it has blocked and prevented me in moving forward in so many ways, and has blocked several options as far as moving forward, and i could not have imagined this when i was starting out.

So what you are saying resinates with me, completely.

September 15, 2012 at 10:05 AM
Dave Moran said...

Thanks for taking the time to comment Erx, and I'm glad this worked for you! It's always great to hear from readers.

It sounds like your in an all-too-common scenario. I don't know about you, but I've been amazed at how long some of my code continues to exist. The life span is always longer than you first envision it...

September 27, 2012 at 7:22 AM

Post a Comment