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.