If only there were more duct tape programmers

Give me a pragmatic programmer any day, there is a time and a place for purists and perfectionism…normally when you have 20 million in the bank.

Please don’t get me wrong all teams need a balance of staff but when you are under pressure you need the guy willing throw the “design patterns” book away so the job can be done quickly.

Anyway, anyone who works with me will know how much I harp on about technical debt, well there is a great entry by Joel Spolsky called “The Duct Tape Programmer”. It’s not about technical debt but about developers who aren’t purists but certainly know how to get the job done, and understand the business need for getting it done as quickly as possible.

Go read The Duct Tape Programmer .

Technical debt doesn’t have to occur because of a rush job, it can happen through being too clever. If nobody else can understand your code unless they have a PhD in Astrophysics then you have technical debt.

Talking about must read articles I read Freakonomics this month, great book – made me laugh and go wow!

Technical Debt, JIRA, priority and severity

“efficiency is about doing things right, while effectiveness is about doing the right things”

JIRA is a great issue/task tracking system but I’m not convinced not having a severity field by default is a good idea, their explanation is;

“The Severity field was removed for a number of reasons, but principally because it was confusing to business users. To a software developer, it seems obvious that the severity of the bug ("The system crashes completely") is unrelated to the priority of it ("There is a one in a million chance of this occurring"). However, JIRA succeeds so well because business users can actually use it.  If you present a business user with these two fields, they are instantly confusing (which is why the Severity field was removed). “

This is a convincing argument. Although, I would suggest that not having severity over simplifies the decision making process. A decision probably best answered for each project individually – experience tells me the business is more inclined to be upset if they create a high severity record and the tech team mark it as low priority.

Decision making

As well as severity and priority should all projects now consider Technical Debt and Financial Cost associated with work items?

Managers require data to enable effective decision making, while a developer may perceive more fields as just being an additional overhead distracting them getting the job done. Technical staff need to be aware of the business benefits and costs of doing something. Spending days refactoring code because the coding standards are not met is not effective if a bug was never reported to do with the code. This is especially true when critical issues aren’t investigated.

I believe Priority, Severity are indicators of technical debt and time to resolve the task is the financial cost. Is it possible to put a value on technical debt? I’m not convinced there is, what I do know is that not paying it off early enough can be very, very expensive in the long term.

As a manager it is important to listen to a team concerned about issues in code and design, the team are responsible for effectively communicating their concerns.

Worthwhile reads – completely un-related  to this blog entry but got me thinking…..

The Kumbaya irony  - Are you having fun with technology for no apparent business reason.

What is Participative Leadership? – getting staff involved in making decisions.

Bibliography

Why doesn't JIRA have a Severity field like Bugzilla?

Technical debt

Finding the value in technical debt 

Refinance Your Technical Debt Just Like Your Mortgage

Paying Down Your Technical Debt

Technical Debt – great diagrams!