Technical debt – developer moans

A few days ago I pushed out a couple of Tweets which got quite a reaction:

“I am fed up hearing developers complain of Technical Debt as if it has nothing to do with them. Who writes this stuff?”

and

“Devs say ‘look technical debt’ like ‘look its snowing’. As if it has nothing to do with them”

It was that second one that got a hail of re-tweets.

So I thought I should add a few words of explanation here.

First it is important to say that the these tweets were not aimed at, or about, anyone in particular. I’ve visited a bunch of companies and delivered a lot of training in the last few months and the topic of technical debt comes up a lot. If I had anyone in mind about these comments in particular it was a developer I worked with four or five years ago but his sentiments are common.

Second, I’m not sounding off about developers. I love developers, I used to be one. I’ve had the same feelings myself at times, speak to people who managed me way back when and I probably moaned about the same things. (Over 10 years ago I wrote High Church C++ where I agonised about the right way to write code.)

What I am taking aim at is an attitude which says: “There is this thing called Technical Debt, we have it, it makes our lives hard, we want it to go away, but we have nothing to do with creating the problem and we need a special solution.”

It sometimes seems to me that having labeled the phenomenon developers are too keen to use the label. Steve Freeman and Chris Matts have tried to recast the debate in terms of real options “Bad code isn’t Technical Debt, it’s an unhedged Call Option”. Intellectually I agree with them but I find that the explanation required to explain an “Unhedged Call Option” is greater than the explanation to explain the original problem so I’m not sure what the metaphor adds to the debate.

The other problem with switching to an “unhedged call option” metaphor is that it perpetuates the Quick and Dirty Myth – the idea that doing a bodge-job now will pay back in shorter delivery time. In reality the reverse is just the case, I gave some statistics on this in my blogs last year about Capers Jones book Applied Software Measurement.

Common reasons given for the existence of technical debt are:

  • It was the developers who where here before us
  • We don’t have the time to fix it
  • The managers made us do it, or The business demands this
  • Its the Architects

(Notice the current developers are never to blame – and as much as I don’t want blame thrown around thats the debate is too often framed.)

Anyway, none of these reasons really stand up to analysis, except perhaps the last one.

Regardless of what the developers who were here before did the current developers should be addressing the issues. It is the current developers who need to live in this code, if they don’t like it they should do something about it.

Sure there may not be time to stop the world and fix everything but you don’t need to. You just need to fix a little bit every time. As Uncle Bob Martin says in Clean Code, follow the Boy Scouts Rule “Leave the code slightly better than you found it.” Then let the Power Law work its magic.

Secondly, there is more time if you do it right. Building quality, bug free, systems is faster than the alternative. Forget the Quick and Dirty Myth, its Slow and Dirty or Quick and Right.

(Sometimes I meet developers who want to “stop the world” and re-write the system. I’ve also on occasion met managers who have bought into this argument and stopped the world. This is a seriously bad idea, its why Netscape no longer exists: developers were allowed to re-write Navigator, as they were doing so Microsoft attacked.

I keep meaning to blog about “version 2” now I must, just watch this space.

Twice I’ve come across Managers who told the team they could re-write. In the first case the managers were lying. The developers, well one specifically, held a gun to their head and said “I’m resigning on 14 February if you don’t let me rewrite”. In that situation you should let them resign, these managers were scared of the developer. As far as I can tell things didn’t work out, the developer left the company not long after and the company was sold.

In the second case the Managers were either stupid or desperate. In either case within days of starting the “Technical Improvement Programme” (TIP) they found it wasn’t that easy and things started to revert to usual.)

Getting back on topic…

Unless Project Managers and Business Analysts sneak into the building at night and change code when developers aren’t looking then managers do not write code. Nor does the nebulous unit called “the business”. It is developers hands on the keyboard, “I was only following orders” is not an acceptable defence.

There is a professionalism issue here. Software Engineers need to take their work seriously and create code they are proud of. This is not to say they should start gold plating things but being an professional engineer means you don’t do shoddy work.

Architects may be the only defence I might accept: however this defence is only applicable when the organisation and architects are committing an even bigger sin, namely Architects who Don’t code, or Architects who don’t understand the system – usually these two go hand in hand.

If the architect(s) code then they are part of the development team, they see the same problem, they have the same complaints. Now it is just possible that the architect does code and they aren’t very good. Or rather, the Architects understanding is different to that of the developers, which might point to issues of recruitment, the architects style or bad team dynamics.

The reason I might accept this reason is that it points to an even bigger problem for the organisation and it does imply engineers are pull in opposite directions.

Interestingly Ron Jeffries replied on Twitter, and said “Ward [Cunningham] originally defined tech debt as reflecting later learning, not available at the time of construction.”

I think its time we returned to this definition. Its not about other developer, the business, architects or others creating technical debt for poor developers. Its about developers improving their own understanding. Its about the need for refactoring. And it most definitely is the developers own responsibility and professionalism.

Heresy: My warped, crazy, wrong version of Agile

I increasingly feel that the way I interpret Agile, the practices and the processes, if different to the rest of the world. Perhaps this is just self doubt, perhaps because I started doing Agile-like-things before reading about XP or Scrum, perhaps this is because my version has always been more informed by Lean, perhaps this is because I have never achieved Certified Scrum anything status, perhaps because I’ve never worked for ThoughtWorks, perhaps because I hold and MBA (and thus have an over inflated opinion of myself) or perhaps I’m just wrong.

Yet clients of mine report some success (I even have a couple of case studies). Perhaps this was despite me rather than because of me. In the past I’ve described two of my own Agile systems – Blue-White-Red and Xanpan, these are my attempts to describe how I see the development working without being constrained by other systems (sometimes I think of own-brand-cola methods.)

Here is where I feel I differ from the Agile mainstream, or perhaps, just Scrum:

  • I don’t it is wrong to carry work from one sprint/iteration to the next
  • I don’t believe in Scrum Masters; where Scrum Masters exists I think they are a kind-of Project Manager; and I believe Scrum Master Certification is a con (but I would, wouldn’t I?) that is potentially damaging the industry and Agile
  • I don’t believe team Commitment works, its too open to gaming
  • I don’t think Agile has cracked the requirements side of the business, we’re working on it, things are getting better
  • I don’t believe Agile has cracked relational database management system; but I think much of the problem lies with the DBMS vendors
  • I don’t believe Agile Coaching is different enough from Agile Consulting to justify the name
  • I don’t really believe in offshore-outsourcing; OK, it can work but the companies that use it seem to be those who shouldn’t and those who are equipped to use it don’t need to
  • I don’t believe you can tell how long a piece of work will take (or how much it will cost) until you start doing it. And I believe it is wrong to pretend you can.
  • I don’t believe Scrum (specifically) really understands the requirements side; and I believe the Scrum Product Owner is a pale shadow of Product Manager role which is (often) needed
  • I don’t believe in One Product Owner to Rule them all; on a large development effort the Product Owner role needs to be refactored (damn, I need to blog more about that)
  • I don’t believe all companies can, or will, make the transition to Agile; but that many of these companies will stagger on for years while more Agile competitors take their market
  • I don’t believe Agile will ever work in Cobol teams, or not Agile-as-we-know it; anyway, Cobol teams which still exists are highly adapted to their environment.
  • I believe Agile is a dirty word in some circles and has been used and abused; but I don’t believe there is an alternative (at least not right now)
  • I don’t believe the Dreyfus model of learning is the right model for Agile, I think it makes work for consultants and creates Learned Dependency, I prefer the Constructivism model

Its not all bad, there are some things I believe:

  • I believe Agile means “Better”
  • I believe the Agile Manifesto is a historic document like the US Constitution, and like the constitution we can read all sorts of meaning into it, depending on who you are you read different things. But there is no Supreme Court to arbitrate on whats-what. So Agile is “what I say it is” – or maybe, like “art is what artists do”, “Agile is what Agile advocates say it is”
  • I believe Agile is, and always has been about flow, some people might not get it, and the some in the Kanban crowd might have come to it late but its always been there
  • I believe in breaking User Stories down – I mean, I’d love it if teams didn’t have to break them down and I aim to take them there one day, but its a long journey
  • I believe the Product Owner role is far more important than the Scrum Master
  • I believe “Project” is an accountancy term that has wrongly become attached to development work
  • I believe in the Planning Fallacy
  • I believe Developers are the centre of the process, ‘Work Flows Inward’ as the Pattern says
  • I still believe in Story Points, or rather, the things I call Abstract Points
  • And I believe Abstract Points should be assigned to task; I don’t believe in using different currencies for tasks and stories (i.e. don’t use hours for tasks and story points for stories)
  • I believe planning meetings, work break down and assigning points is as much about design as it is about work scheduling
  • I believe engineering quality is essential to achieving Agility
  • I believe in Software Craftsmanship and don’t think Agile will ever work if quality isn’t fixed
  • I believe every organisation has to define its own version of “Agile” – you can’t take Scrum (or any other method) off the shelf
  • I believe too much advice and consultancy can stifle an organisation, I believe in light-touch consulting to help companies find their own path
  • I believe that in many companies – corporate IT departments specifically – the right approach is to “do things right, then do the right thing”
  • I believe when you apply Agile thinking outside of IT it is Lean
  • I believe speaking out against Scrum is bad for the reputation and the Scrum Mafia will come after you in a dark alley

Gee, this starts to sound like Allan’s manifesto! Anyone want to sign? 🙂
– OK, the last point was a bit of a joke 🙂

I’ve linked to some blogs and such where I have previously discussed these items, and I might expand on some in future. Many of the issues raised here are complex and I really don’t have the time to explain them right now, so next time you see me ask me to discuss.