Number 1 cause of unmaintainable software code

MUST READ: if you want to be able to maintain and adapt your software to the ever changing world of business and technology.

Explosion of technologies

We’re living in a world exploding with new technologies and programming frameworks every day. Each one of them has advantages and disadvantages, supporters and opponents. The purpose of those new technologies is to try and make our, the coders’, life easier by shortening the time of delivery, by simplifying the accomplishment of typical tasks like creating UI (User Interface), providing CRUD (functions to Create, Retrieve, Update and Delete), ORM (Object-Relational Mapping), or whatever else. Every coder needs to make a decision to concentrate on a set of technologies, understand them, become professional, in a strong belief that they don’t become obsolete too quickly. You simply can’t concentrate on everything, you have to choose…

Example technology set

I like talking about real life situations, not general problems. Let’s assume you are a coder who decides to follow the Microsoft .NET path but has to be very flexible about technologies around .NET. Typically you’ll use C# or Visual Basic and produce DLLs and EXEs. Also you may use ASP.NET with its aspx code files and supportive css layouts. Or cshtml for Razor which is more readable and supports Intellisense better (at least some of it) in MCV 4 and newer. And you have LINQ with its anonymous types and dynamic variables that get type only at runtime. On top of that you have a database, let’s say some version of MS SQL and ORM framework like Entity Framework in a version that you’ve learned for data exchange purposes. And let’s be optimistic – you understand all these technologies to an extent that allows you to create nice applications. Oh, I almost forgot, there’s also Javascript that allows more responsive WWW user experience, together with AJAX and JSON maybe that accompany it. Let’s also assume that you’ve made it through all technical obstacles that these technologies hide, so you are not a slave but a master.

To summarize, we have this set of technologies as an example of a software project framework components:

  • C# (or VB) with dynamic variables, anonymous types and LINQ, version 5.0
  • .NET (or Razor)
  • Javascript, AJAX, JSON
  • MS SQL


Greenfield ? Forget it !

Did you notice that all examples of code found on the Internet, including MSDN documentation, tech blogs, stackoverflow discussions, codeproject portal solutions and so on assume that you are free to create from scratch? Which… is not the case in ca 90% of projects…. Either you end up with a so called brownfield where legacy modules exist or your own software must evolve, because its first version (that was a so called greenfield) is no longer useful and must be adapted to new business processes and opportunities. What happens ?

Unmaintainable code

Yes, what happens now is that you are about to change your beautiful and working code and this change is going to take waaaay too long to be covered by a budget you can get. Why is that ? It’s because even if you are an OOP (Object Oriented Programming) geek, you are in a web of different technologies that interweave but do not offer a coherent OOP approach across all frameworks. If you change something in the C# code, you have to adapt ASP or Razor. Then you realize that your CSS is not aligned, your Javascript has to be adapted,  and SQL code must be changed (stored procedures, functions, or tables). And even then your code is going to throw an error on site – in your customer’s production environment with an unhandled ‘reference not set to an instance of an object’ exception, and you will have no idea why.


Take a step back – SRP

Where did I go wrong, you ask yourself. The customer is angry, profits don’t come, your staff becomes nervous… I’m sorry, but you broke one of the basic rules of object oriented programming: Single Responsibility Principle. Don’t spread responsibility across all these technologies. You can’t maintain a code where changing a column in a database table requires changing C# code, javascript code, ajax code, JSON code, stored procedures’ code, SQL functions’ code, and even then it destroys user experience by throwing unexpected exceptions because you love dynamic variables in javascript and the latest version of C# so much. I’m sorry again – it’s laziness that kills you now. All those technologies used in a way that makes it impossible to change code in one place without adaptations in several other layers means only one thing: you broke the SRP.  Yes I know, there are coders that do not follow the OOP programming rules at all and their software is not even maintainable in the C# area not to mention other frameworks. But let’s assume you are an advanced dev or project manager and you are way ahead of these losers.


Slave of new technology

Even now millions of developers use Visual Studio 2010 that does not offer a full intellisense in ASP versus C# code behind, not to mention javascript, strong types, or type checking at compilation in various situations. Millions of developers have no idea whether each component of their software works with each other until they  run very comprehensive, time consuming tests (which cost money) and repeatedly correct their application. Or, more likely, until their customer calls about unhandled exception or unexpected application behaviour after an update… All those poor suckers believed in the marketing hype of new technologies and frameworks. Yes, these technologies shorten the time of delivery. Yes, they help you in producing less code to achieve a similar effect. But still, they do not offer Single Responsibility Principle mechanisms at the time of design and compilation across entire application.


Number 1 problem

So my number 1 problem in today’s world of software development is that  we have too many promising technologies… Technologies and frameworks are still too far from each other, and people using them quickly spread all their knowledge and effort across all technologies thus breaking Single Responsibility Principle. In a strive to stay modern we lose sense of proportion. All these technologies are only tools, and we have to be smart enough to keep following rules that make it easier to maintain quality and fast delivery while using them.


What should I do ?
Well, I need to warn you. All those new technologies are presented in a way that is supposed to encourage new developers to come into the scene and use them. This in turn provides more sold licenses to Microsoft or any other company that offers those technologies, which is fine. But don’t get fooled by all those pretty adverts claiming it is so easy to create applications these days. This simply isn’t the case in real life, in really advanced applications that you are after, my friend. Unless your project is a greenfield (even then it’s only easy with the first version), a program for private use, school activities or one shot simple software. For advanced software that needs to be continuously changed and improved you need plain old object oriented programming and responsibility situated in one place.

  • Don’t use SQL procedures nor functions if you don’t have to

Do not put logic in SQL procedures or functions until it’s the only option (for Do not put logic in SQL procedures or functions until it’s the only option (for optimization reasons). Sometimes you need to use SQL’s special capabilities to get a view or report of some kind. SQL is typically better in fast relational joining than C#, which is really slow when doing for/foreach loops. But for a typical CRUD operation you should avoid procedures and functions like a plague. Exception: procedures are ok if they are automatically generated with an ORM framework which makes them adapt if a change in the model occurs. Don’t rely on humans, humans make mistakes.

  • Javascript, JSON not coherent with business logic and model

Do not put any code that is model related (e.g. column names, entity status) in the Javascript part of your application. Javascript has to be totally transparent and accept all data related changes in your code without adaptations. There may be some exceptions but they’ll cost you time and money to document and adapt every time you change the data source. Don’t use Javascript for business logic but to improve user experience.

  • ASP/Razor not coherent with C#/ SQL

Same goes for web interface which is very often not 100% in line with ever changing model and business layer. Try to make it transparent to database changes. If you need to change a view (grid, details panel, buttons, etc.) dynamically, don’t code the necessary logic in the view. Do it in a separate class or other part of the business layer. The one where you ask your business objects if some grid column can be visible or not depending on privileges and/or state of an object, whether an action may be presented to the user or not or if some buttons should be clickable or disabled. A view is a view, it should contain no business logic at all or as little of it as possible.

  • Dynamic variables/anonymous types traps

Oh, you love them. Strongly typed software becomes like AI, guessing your intentions… Wake up! In a constantly changing world, changes in business processes may degrade the quality of your software in a blink of an eye. The compiler cannot guess all problems that may arise when you use dynamic variables that have no meaning until you run your software. (the situation is much better in case of dynamic variables the type of which has to be guessed by the compiler at the time of compilation. Still, you need to remember they may become null if computation leads to it). Even if you’re simply displaying data, the data may be corrupted by formatting (comma, full stop, date formatting, too long strings etc…) – don’t rely on C# and Javascript dynamic variables that much: the compiler will not warn you that you can’t divide or multiply dates or strings. You will be warned by… your customer.


Yes, I know there are thousands of other reasons why code can become difficult to change and adapt but my ‘numer 1…’ assumes the readers are advanced developers and/or project/quality managers and follow basic object programming rules.


Other related articles

Thanks for reading and regards

Dominik Steinhauf
CEO, .Net developer, software architect

If you need help with your software project, or need customized software for your company, contact me at: dominik.steinhauf ( at)

Leave a Reply

Your email address will not be published. Required fields are marked *