Technical Debt In Software – The Fine Line Between No Architecture and Over Architecture

As I am writing this, I am sitting on my condo’s terrace in downtown Toronto, baking in the sun while I take in the noise of the city and cars and people down below at the street level.  There is a helicopter that seems to be circling the downtown core for quite a while now.  It’s freaking hot today and I could probably use some water.  Be right back.

At the time of writing...

At the time of writing...

(1 minute later…)

Ok – water has been acquired….. I also grabbed a Kilkenny and poured it into my Kilkenny glass (Kilkenny requires the right glass to be enjoyed properly)

It’s been a while since I’ve posted, and career wise a lot of big and exciting changes have been made.  I made the move to independent consulting, and I am enjoying it big time!  Now my efforts are shifting from helping one organization develop bleeding edge scalable systems to helping many organizations with development, architecture, minimizing technical debt, and team building.

Along the lines of the type of work I’m focusing on, I want to write a bit about bad architecture, over architecture, and technical debt.

Ok, so I’m going to talk about the benefits of a “value added approach” to software.  I’ve seen a lot of systems in my day – ranging from poorly architected apps that deliver high amounts of business value to over architected systems that, instead of delivering their expected business value, became a total utter failure for a multitude of reasons… and everything between.

To the business, a successful system is typically one that delivers on it’s promises on value to the business.  The negative impact of technical debt is not always seen by the business teams and is sometimes seen, albeit indirectly, as “necessary”.  So, in these scenarios – why is it necessary?  is it job security for the dev team? Lack of training?  Lack of standards?  There could be a plethora of reasons, but in the end the technical debt introduced by these systems is high and could cost the organization millions of dollars.

High business value systems and mission critical systems can suffer from an endless amount of technical debt due to lack of design standards and architecture.  This technical debt is not always apparent to the senior business teams. The business loves the system however, but they sure don’t understand why it takes such a long time to add new features or track down bugs.  The business leaders at the top see the system as great too, but the fact that it’s overly fragile, requires daily maintenance and an overly large team just to support it seems somewhat necessary – plus it’s “just the way it is”, right?

The real deal here is that technical debt, and overly large dev support teams are just not necessary at all.  The right people, training, technical skills, system architecture, and business leaders have the potential to create the right systems and find that fine line between a proper development architecture and business value.

Yet, there is another extreme…..Over architecting and big ego’s….

People have ego’s… Fact of life .. When architecting a system, I’ve seen many software architects with an ego.  Their system is great, using all the right design patterns.. Look at how cool my undo system is with the command pattern implementation I came up with.  Watch how I can add one entry to the configuration file and all the sudden the entire behavior and business logic of the app can be changed… Our customers can now create their own custom modules using my handy dependency injection techniques and augment the app with their own fancy things they want to do…..  Pretty sweet eh?

I agree, ok it’s pretty sweet (and fun to work on) and I’ve seen and created my fair share of ‘coolness’ in my systems.  There are always business cases for these types of things and having the right technical team and abilities to implement them properly is key.  The problem is over architecting when they aren’t needed or for the dreaded reason ‘just in case in the future’.  The fact is, this can sometimes delay shipping the product and complicate the development.  There is typically a big disconnect between the development team and the business value in these scenarios.  You end up having a technical team who is more focused on architecting than on providing business value.  Focus on what’s needed, and if it is, and there is a case for having it… Build away and have fun!

Both of these scenarios above can lead to long term technical debt.  The trick in software is building a team who can leave their ego’s out of it, share knowledge of the system and the business value proposition, and focus on what’s important for the long term success of the project while minimizing technical debt.  Doing this has the potential to create phenomenal systems that are well architected, bugs become easy to track down, the system can grow organically the way it needs to, the size of the development team can remain minimal, and the business is happy knowing that maintenance costs are reduced and new features can be added to the system quickly.  There is no more fragility – the system becomes clear and small changes are less likely to have unexpected bad consequences.

There is a fine line between both of these scenarios and it requires practice and discipline to build the right team who can achieve and continually create well architected solutions that maximize business value and eliminate technical debt.  It can be done and can be done very successfully.  To truly master this as a software/business team, it needs to be instilled as part of the culture of the team.  The right leaders and people are very important in truly creating world class software solutions.

About dandouglas
Dan Douglas is based in Toronto, Ontario, Canada and is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 15 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results. | For inquiries about Dan's software consulting practice, please see the contact page.  Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

5 Responses to Technical Debt In Software – The Fine Line Between No Architecture and Over Architecture

  1. I completely agree with you on the supposed “coolness” of over-architected solutions that are designed to be super-duper flexible, decoupled and configuration-driven but in reality end up being disjointed, fragile, impossible to troubleshoot and difficult to enhance. In fact, I happen to work on one such system at my current client, and I could probably write a case study on how NOT to design an enterprise-scale architecture based on my experience here — that is, if I had the time and inclination to write. :)

    Oh, yeah, and I also totally agree on the “drinking Kilkenny out of the proper Kilkenny glass only” thing. Cheers!

  2. Steven Lane says:

    Great article Dan. I too have seen both sides where an app is done on the cheap, rushed into production, and everyone is happy, until the support requests roll in and it becomes a support nightmare, and thus a money pit. It seems to get even worse when the same approach is taken to fix or upgrade the app, but it is usually done by a different developer and becomes a big mess of spaghetti code, becoming even more of a support nightmare because it is harder to follow, and each of the previous developers points blame to the other. I found this particularly troublesome in huge organizations with massive datasets, but the foot loose and fancy free developers don’t look outside of their application to see how it will affect everything else, or even what part they can pull that are already there instead duplicating data. Oh man, it’s getting me frustrated and bring up bad memories while I type.
    And on the other hand, have seen the business super upset and disappointed when a new version they had been hoping for (because the original was an example of the first) eats up all the time and twice the budget before it is half done because the developer was being a hot shot and overdoing everything and putting in all the latest technologies that didn’t necessarily work well with other things that already existed so needed to make other pieces to interface between them (which was already a major drawback of the original system, but he was cool for being able to do it). He was a great architect/developer, but it cost the business a fortune and they didn’t get what they wanted.

    It is a fine line that can be hard to distinguish, and the problem is that technical debt has become the stereotype for software development. Either side of the spectrum means the same thing for the business.. more money and headaches. In the end, both sides give all IT businesses a bad name. Makes it a lot tougher for us in the long run.

    Well my comment is a lot longer than it should be, so I will stop now before it gets any longer. But will now pose this question. What do we do to instil this in our team? Or on our own, how do we reduce technical debt, to make a better, happier client that will keep coming back?

  3. dandouglas says:

    Awesome comments Steve and Tim.  Here is my response – please respond if you like.
    There are a lot of factors to look at to find that ‘fine line’ between over architecture and no architecture.  If we are looking at a team, some questions to ask might be – How well is the team working together?  What are the team dynamics like?  Solid trust within the team?  Is the team focused on team goals and team wins or is it more or less individuals on the team looking more for personal glory or wins as a higher priority than the teams goals?  Or, does the team even have any team goals – is it strictly individual goals that are being strived for?  Are people afraid of their superiors and feel free to provide their own opinion even if it seems constructive in order to better achieve the right team solution?

    Asking these questions can help narrow down if there are general team problems that are contributing to the software problems…

    If it’s a team problem, I’d suggest starting improvements at that level.  Strategize some team building sessions, meet weekly to discuss and resolve any issues from the prior week (in agile environments, this would be done at the retrospective at the end of each sprint/iteration.). Get the team working together, setting goals together, and build a culture where the team is working together all the time.  People aren’t afraid to speak up and everybody is working together to improve because the only goals that are important are the team goals.  If the team wins, everybody wins, if the team loses everybody loses.  

    The teams that are the most successful are the teams that work well together.  This creates a much bigger win than individuals working in silos would be able to do.  The result in software is much much improved software and less technical debt.  The same could be said for a sports team or a team of any nature.  

    Ok, so that’s some basics around team stuff and sorting out team dysfunction.   A little vague, but hey I’m trying not to make this comment into a novel….

    Once that is sorted out you need to collectively create goals.  With mutual respect in place among team members, better architectural discussions can be had with everybody speaking up about the architecture and coding standards.  And do some pair programming as well :)…

    Some say code reviews are ineffective and don’t work.  They do work, I’ve seen them work.  So, try code reviews.  A great way for the entire team to review and interact on existing code and talk about refactoring for future software updates.

    Understand the business requirements as best as you can up front, ask the right questions, and get everyone on board with where the software is going.

    One thing I’ve always done when thinking about what to include in an architecture is come up with a scenario where the said architecture or pattern will help solve a problem (problems could be barriers to implementation, complexity concerns, business use cases, etc) and think about how the architecture lends itself to that.  Look at the cost of implementing and maintaining the architecture and also the learning curve required versus the added value you are providing.  Sometimes, I’ll half ass implement a pattern just so it’s there and if I really need to fully implement it in the future, the refactoring is simplified to make it so.  This is to have a minimal affect on maintainability and over architecture as it creates a scenario where you can do the architecture up later when needed without mega refactoring.  

    Also – try not to create lists, weighting scales, or pro and con arguments on paper or a white board.  If you are solo just take some time out and really think about it, and talk to colleagues about it.  In a team, get the team together and pound it out.  Don’t analyze it to death though, it’s not worth the cost of that ;)

    Have the architects create a vision and strategy and then discuss it with the entire team to come up with something even better. Implement it and continually review and adapt it as necessary.  Don’t have someone make an individual decision about an architecture or pattern and then leave it to the other developers to have to deal with it and the technical debt it could create. Always get team buy in for technical strategy.  Someone at the Senior Architect level, by my standard, should surely know how to listen and communicate with the developers on these types of decisions in order to get the best possible outcome.

    Wow, this is a long comment.  I just sat down with my iPad and started typing.  Yikes…maybe I’ll turn this into a blog post later.

  4. Pingback: Qué hace un desarrollador - ASPgems

  5. Pingback: Qué hace un desarrollador | ASPgems - Soluciones ágiles

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