Follow-up on duct tape programmers

Just read Beating the duct programmer with generic domains, subdomains, and core domains. Great explanation of when you want to apply software engineering and duct tape programming. As I’ve said before - there is a time and place for good software engineering and a time to just get the job done.

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!

Your Greater-Than-Yourself Project

“Greater than Yourself”, is a great principle principle to have but I’m not convinced it can be achieved in isolation, unless you feel critical mass can be achieved.

Helping others to achieve their potential is something I’ve tried to apply in my working life, to varying degrees of success. The Harvard Business article “Your Greater-Than-Yourself Project” defines a concept to developing others and has certainly focused my mind on where I and others have done it well or poorly.

Whether you are an executive, team leader or junior in a team I think it is invaluable advise – I’m just not sure how easy it is to be completely selfless, especially when times are hard. A nice principle to aspire to.

The article states that the mentor should expect nothing in return, I have always believed that growing a network of successful people means that I can be more successful, so maybe I’m not entirely selfless.

References:

http://blogs.harvardbusiness.org/cs/2009/04/the_secret_of_great_mentors.html

New addition to the family

New addition to the family, originally uploaded by garyt70.

With a look like this how could anyone not want Willow to be part of our family.

Think….

What would you do if your Facebook, YouTube or Blogger account was removed????

http://www.chrisbrogan.com/youtube-is-not-the-internet-but-she-has-a-point/

 

I don’t expect everyone to agree with the content of the video contained in the above blog (that’s assuming YouTube hasn’t removed it of course, and it’s not obscene, just food for thought). It does make me think about what would happen if Google decided my blogger account was unacceptable and deleted it.

Patent wars stifle innovation

Interesting that Red Hat seems to think it owns the rights to XML data routing. Altio has a similar, if not the same, patent claim from 2003. At present Altio does not want to get into a legal battle over who’s patent is more valid, preferring the innovation approach to stay ahead of the game.

Software patents are a controversial subject with strong feelings amongst the developer community, I feel they are now a part of running a software development company. If you do not wish to take the patent path then it is important to ensure you make a public statement about an innovation. Without public knowledge an organisation is at risk of a megavendor claiming a patent and making life very difficult for small software houses.

Unless an organisation can innovate faster and better than everyone else and are not concerned who uses the innovation then I feel patents, as a defensive measure, are necessary. The problem with being innovative is that it costs money upfront, using somebody else’s idea is easy if you have lots of cash available. Sometimes the small vendors may just need to make a stand and use their patent for financial gain and maintaining market position.

Ideally software companies would get on with being innovative and writing good quality software. Instead all the big players look for are ways to make a quick buck at the expense of innovation. If you’re an innovator you just want to write good code, not fight legal battles.

It appears software patent litigation may become a normal part of being in the software industry.

http://www.theregister.co.uk/2009/03/16/red_hat_patent_app_dynamic_routing/

http://www.freshpatents.com/-dt20090305ptan20090063418.php

http://www.wipo.int/pctdb/en/wo.jsp?IA=GB2002005577&wo=2003049369&DISPLAY=CLAIMS

http://www.freesoftwaremagazine.com/columns/whats_wrong_with_software_patents