Modern Software Development - Why Less Code is More

StarCIO Less Code is More
Last week I participated in a panel, "The Future of Software" at the Northeast Javascript conference and was asked a question about code quality. "Are you seeing better or worse code coming from developers today?"

"I am seeing less code today."

I'm not just talking about low code platforms that can enable software developers and citizen developers to build entire applications with relatively little or even no code. I'm speaking about applications where you have to develop proprietary code but can accomplish your objectives with minimal coding effort. How? By leveraging programming environments, frameworks, and libraries that do most of the heavy lifting for you.

Stories from the trenches on too much code


Let me share a couple of stories with you. First, about an application that I reviewed about fifteen years ago that had over one million lines of PERL code. Now the code base leveraged frameworks and libraries and was very well structured into modules and functions. I don't think very many people would call it "bad" code, but it was big and complex. When it came time to update the code to add functionality or improve performance, the development team struggled to understand dependencies and perform end to end tests. That code base ended up getting rewritten largely to address performance issues, but the secondary objective was to put it into an application framework and better enable a larger development team.

Here' another story at a different job. About five years ago I was week one in a new CIO role and was asked to go and review a new product that was under development. It was May, the product was due in August, and the team was following "agile" so I asked to see a demo. As I recall, the demo was of a single screen, a dashboard with a handful of charts that let's just say looked less than impressive. More precisely, it looked like something out of a 1980's version of Lotus 123. I then asked to see the code that generated the dashboard, so the developer proceeded to walk me through several hundred lines of code it required to generate it. That product had to get a restart, first because the project wasn't anything close to being agile, but more importantly, because we needed to switch platforms. While the underlying BI framework was powerful, it required way too much programming to perform even basic data visualizations.

Why Less Code is More


With today's software development frameworks, code quality should partially be judged by the "less is more" metaphor. With all of today's technology, you should be seeking out frameworks that meet operational, security and other criteria that enable the productivity of a team of developers, not just your star developer that has enough talent to get things done without a lot of help.

Why is this so important? Because application development isn't just about getting 1.0 out with a superior customer experience on time and on budget. If you're agile, 1.0 is just the MVP and the organization should be planning to do enhancements, fixes and other upgrades. With less code, you have less to maintain. In general, you have fewer dependencies and complexities for new developers to understand before they implement changes. You have fewer places that you control that can negatively influence performance, scalability, or security.

It's not the only code quality metric. I also look for modularity, evidence of reusability, the presence of naming convention, and the existence of unit testing. But if it's a large code base I know I have an uphill battle.


5 comments:

  1. This reminded me of my days in code quality, impact analysis when spending a million dollars on a tool to help your developers grep through millions of lines of code (think Lucent) faster was money well spent. Over time these tools got more sophisticated (not sure if any could work with PERL well in the day - poor embedded guys) but you make a valid point to consider the "source" of the problem. One I am surprised I hadn't thought of earlier given my experience with those tools starting with DISCOVER in 2000. Eliminating the need to build less critical apps with expensive developer resources and programming languages, freeing up your key developers for more important matters is a good strategy to employ using citizen development. Delving into an app built with a low-code platform years after it was created is undoubtedly much easier than something that required 50,000 lines of Java and .NET.

    ReplyDelete
    Replies
    1. It's counter intuitive to some developers who just like coding. Some will find reasons to build their own frameworks and libraries because they are looking for something better than what already exists. I was encouraged at the NE JS conference as the consensus was use what's available and if something better is needed, contribute to an existing open source framework.

      A real and bigger issue is when business leaders and product owners drive requirements toward custom work, especially when a dev team offers them low code or out of the box alternatives.

      Delete
  2. I partially agree with you Isaac. The SOLID principal needs to be applied to most projects, but relying on frameworks alone is dangerous. First, have you seen the dependencies for some of the current frameworks? They may easily be over a million lines of code between the various dependencies that make a framework possible. And in most cases, those are black boxes. Another issue is the differences between versions. Look at Angular 1.0 and Angular 2.0 release candidates and finally what actually shipped as Angular 2.0. Very drastic differences.

    Bottom line is that you have to have a good balance between developers, technology and platforms. It's not about the number of lines of code written, it's about their efficiency, and about how easy that code is to maintain.

    ReplyDelete
    Replies
    1. Frameworks - both open source and commercial that put organizations through major redevelopment and testing on releasing new versions is a major concern. It's a serious problem, effectively boxing many orgs/apps into legacy versions or forcing businesses to schedule and invest in major upgrades. The most mature and skilled frameworks recognize this issue and take steps to alleviate the efforts required to test or recode to instrument an upgrade, but it's hard to know who does this well especially for newer frameworks.

      Agree on code efficiency, but it's an imperfect measurement. Fewer lines of code can also be misleading. Best measure may be how long it takes an average->good developer to say, "Ok, I get it" regarding existing code and can update it effectively.

      Delete
    2. In case of Angular, Google is providing an upgrade module, that allows you to switch smoothly to version >= 2. That just shows me that Google understands the concerns of business to secure their investment.
      Further more I'd rather choose one of the current major frameworks over implementing it on my own.

      I also can't support the argument that the framework are often a black box and therefore you shouldn't use them. Technically they are open source and you can actually look at the code. Practically they are that huge that they are more or less a black box unless you have been working with them for years.
      Following the thought, you would have to ask yourself why you are using mysql, Linux or any larger framework.

      My article on www.rainerhahnekamp.com/en/modern-software-development/ has even a stronger opinion towards the usage of frameworks than Isaac's one.

      Delete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share