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

Delegate, and bite your lip, but don’t stop communicating.

One of my greatest frustrations at being a manager and solution designer is coming from a software development background and having to delegate coding tasks.

So why do I delegate and get frustrated.

I delegate because I do not have the time to do everything I want to get done. I have to rely upon others to do what I once could easily have done. Delegation and communication is what makes an effective team and team leader.

My frustration isn’t because I think I can do it better (well maybe it is sometimes), it occurs when someone finds excuses to not do the job properly – this can be colleagues at work or a teenage son. If you are going to do a task, even if it is for a demo then do the work properly and as if you are going to sell it later – in the case of software this may well be the case and so you want to avoid financial and technical debt.

So while a may I feel like telling people to “just get on and do what I asked”, this wouldn’t always be effective. Delegation relies upon effective communication, and sometimes this means cajoling someone into delivering what you want rather than what makes their life easy, this can be quite frustrating especially if you have to keep doing it.

Enabling someone else to do a job requires

they know what you want

they have the authority to achieve it

they know how to do it.

 

If you feel above three items have been done then it is down to the person you have delegated to to communicate effectively with you, especially if they are unsure of their responsibility and what is expected of them. Otherwise the task is at risk of failure.

Every article you read on project failures should mention “lack of communication” as one of the causes. Poor requirements lead to misunderstanding, lack of developer feedback and demo’s leads to misunderstanding – especially in agile projects.

So you can delegate and bite your lip when getting frustrated but don’t stop communicating otherwise you are at risk of not delivering the task.

You can delegate the work but not the responsibility!

 

Bibliography

 

http://www.see.ed.ac.uk/~gerard/Management/art5.html

http://www.bizhelp24.com/employment-and-personal-development/the-art-of-delegation-2.html

http://www.talkbiz.com/digest/emt17.html

http://thompson-web.blogspot.com/2008/04/project-estimation-duration-effort-and.html

Protectionism Leads to Conflict

I recently subscribed to Executive Advisory and the most important entry on any blog I have read recently is on the subject of protectionism within the organisation.

http://eapblog.burtongroup.com/executive_advisory_progra/2009/03/protectionism-leads-to-conflict.html

As far as I am concerned it is everyone’s responsibility (politicians, executives, staff etc) to identify when protectionism is impacting the chances of success, effort should be focused more upon working collaboratively so that everyone gains.

If you type “protectionism” or “psychology protectionism” into Google or any other search engine you will see there are numerous articles in favour or against protectionism. So I guess everyone has a choice to make.

For me right now I am against protectionism, I see it as damaging for both organisations, relationships, and economies.

JQuery, XML and namespaces

Being awake at the early hours of the morning I decided to try and take my mind off of product strategy and increasing market share, so I decided to play around with Altio 5.3 (pre beta) REST services.

The challenge I set myself was to use JQuery to retrieve data through the AltioLive Presentation Server (APS). I thought it would be easy, after all it’s easy in AltioLive.

The problem I encountered was namespaces.

It seems JQuery doesn’t handle namespaces very well, as described in ticket 155.

The solution for me was to use the following syntax ‘namespace\\:element_name’ ;

<atom:entry xmlns:atom="http://www.w3.org/2005/Atom">
...
<atom:content type="text">blah blah</atom:content>
</atom:entry>

Now if that document is stored in a variable named xml:

$(xml).find('atom\\:content').eq(0).text()

Will return the text of the atom:content element.

 

I found this out courtesy of www.xml.com http://www.xml.com/cs/user/view/cs_msg/4298.

 

Not sure if the syntax is correct, but it works in FF and IE using JQuery 1.3.2. I managed to read a fair number of blog entries, and information on processing XML with namespaces, the above was the only approach that worked for me.

Other sources of info:

http://www.xml.com/pub/a/2007/10/10/jquery-and-xml.html

Technical debt

What a great term “technical debt”.

I picked the term up from Martin Fowlers blog entry call “Technical Debt”. You also need to watch the video talk by Ward Cunningham to understand the background to the metaphor.

Debt

When developing software you can accrue two types of debt, financial and technical. Both can result in the failure of a project or organisation.

Financial debt is common to everyone – you have to pay salaries, rent and for computers etc. If you are lucky this is paid for through income, otherwise by borrowing.

Technical debt according to Cunningham is not about poor code but writing the best code given your understanding at the time. You can rush software out of the door, but you incur debts which may need to be paid back. I say “may” because if the software is not successful or is meant to be thrown away as an experiment, who cares if you cut corners. Unless of course the reason for failure is because you cut corners.

Don’t accumulate financial debt for the sake of reducing technical debt unless you are very confident of success.

Technical debt can be as crippling to the roadmap of a product as financial debt. I feel the difficulty for someone managing software projects is balancing both debts and negotiating with stakeholders and development teams to get debt balance right.

Don’t pass the debt on

My personal choice is to write the best interface to the outside world in the hope that end users not impacted by later changes. If you don’t put enough effort into achieving high quality external interfaces then you are passing your debt on to others, especially if changes need to occur later.

This may mean that the internal features not expected to be used by others must accrue your technical debt. The technical debt has to be paid back through refactoring later.

Don’t hide the debt

As the financial credit crunch has shown hiding bad debts in clever delivery mechanisms can only lead to disaster, especially when it gets to the point when nobody understands what is going on, or does not want to understand because things are great at that moment in time. If the project is accruing debt make contingency plans, and make it clear to stakeholders why the contingency plan is required and the risk the project is exposed to.

The bottom line

Don’t try to achieve perfection first time, unless you have lots of money to spend. Get the balance between a perfect system that you can be proud of and a system that delivers business benefit with the least financial and technical debt.

Financial debt is short term, technical debt is long term but can be addressed after first succeeding, once the money is flowing you won’t incur further financial debt.

Finally, it is better to deliver a working project than to never complete a perfect project.

Forgot to add this reference: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

View from my new office - sunset

View from my new office - sunset, originally uploaded by garyt70.

January has been extraordinarily busy, February is working out to be the same.

Decided to make at least one post that stays in place after several failed attempts to do a blog entry with JavaScript and DHTML.

This Photo is from the office window in the building Altio has moved to, nice views all around.

Agile explained in simple terms

Neill, sent this link to me http://www.vimeo.com/user1195135/videos, I think its a great way of using Lego and learning Agile software delivery.

Neill, learn to use your Google phone to twitter! You could then post a video of it :-)

 

 

User Stories from Agile Advocate on Vimeo.

26 - 30 Jan - Altio Roadmap - USA Clients

Next week I'm going to be visiting a number of cities in the US discussing the AltioLive roadmap with clients. If anyone is interested in meeting for breakfast or in the evening to discuss RIA technology trends and the Altio roadmap drop me a line at gary.thompson@altio.com . It's quite a busy schedule so I can't promise to meet all requests.

 

Itinerary

26 Jan - Palo Alto, San Franciso

27 Jan - Palo Alto, San Franciso, up until 11am when I fly to New York

28 Jan - New York

29 Jan - New York (morning), Boston (afternoon)

30 Jan  - Boston

 

Roadmap agenda - usability of RIA applications, report generation, user computing, rapid development of RIA applications.

Australia - the missing weeks

OK, due to the lack of Internet access I didn't manage to blog everyday when in Australia and so have decided to do a late update on the trip. More as a reminder to me of a great holiday (photos are on Flickr).

Sydney – Tuesday, 16 December

Blue Mountains – well worth the journey into the mountains for some spectacular views. I have to admit getting the late tour out of Sydney was a bit of a mistake as it meant trying to cram too much into the day.

Sydney – Wednesday, 17 December

Sydney Botanical Gardens – everyone got up late after a long day yesterday, so we spent 5 hours exploring the Botanical gardens looking for parrots, bats and other native Australian wildlife. Oh and we looked at some plants as well.

Sydney to Brisbane – Port Stephens, 18 December

Lots of travelling. The camper van is HUGE, it’s like driving a 7 ton lorry. I can now say I am now one of those people who can cause a 1 mile tailback of traffic.

I was impressed by how helpful Australian police are, I guess they are used to Poms getting lost looking for Lemon Tree Passage (Port Stephens), not so sure British police would print maps and even try to see if a patrol car is going in the same direction.

We spent our first night in a camper van right on the edge of a river. I have to admit it takes some getting used to seeing Parrots and lizards wherever you go.

Sydney to Brisbane – Coffs Harbour, 19, 20 December

OK, Australia is seriously big, and I’m not convinced their 1km is the same as the rest of the world. Over 400km today, by the time you travel up and down several mountains I’m sure it was more like 600km. I’ve discovered you can get a 7 metre camper vans around some very tight bends – at one point there was nothing to the left except a 100m drop. Future note, when driving camper vans through Australia carefully consider the use of some tourist routes, they can be a major detour and take hours to complete.

Stayed at Darlington beach campsite just outside Coffs Harbour. The campsite is literally on the Corindi beach so you get to listen to the sea while watching the Lorikeets (birds a bit like Parrots).

Sydney to Brisbane – Tweed Heads, 21 December

Final stretch. Had to make a stop at Byron Bay, the most easterly point in Australia. As we had the camper van it wasn’t possible to drive to the lighthouse – something about the roads being too narrow. So we had a choice of walking 2.2km along a road or 1.5km through the woods.

The vote went of the scenic 1.5km walk. When it’s over 30C and you walking up some very steep slopes 1.5km feels like a very long way.

On eventually reaching our next campsite all we wanted to do was wallow in the swimming pool. I have to admit we have all spent more time in swimming pools than we ever would in the UK – I can’t see how Australians could survive without one.

Brisbane, 22 December

Koalas, Kangaroos, Possums, and Lizards – we went to Lone Pine Koala Animal sanctuary to cuddle Koalas and feed Kangaroos, well worth a visit.

Oh buy the way as Milly found out when cuddling Koalas you need to be aware that they poo (A LOT), and you have to hold their bums, yukkkkk.

Port Douglas – 23 to 28 December

Daintree River, Kuranda Railway and Cable Car, Relaxation, Great Barrier Reef.

I have to say if you get a chance to go to Australia then visit Port Douglas. There are no franchises, so no Starbucks, McDonalds etc. This means you can really separate yourself from the rat race in the rest of the world. If I should be lucky enough to return to Australia I will make sure Port Douglas and the Sea Temple is on my itinerary.

Brisbane, 29 December

Thunderstorms.

Our last night in Australia was spent watching a fantastic storm.

 

Conclusion

If I could repeat this holiday I would skip the camper van and fly direct to Brisbane and then hire a car. Aside from that this was a perfect holiday. 2 weeks on and back at work is depressing as it feels like the holiday was years ago.