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

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

Design Methodologies - where do you want to spend your money?

I recently revisited articles on design methodologies, specifically TOGAF (The Open Group Architecture Framework) and Agile methodologies. Initially, I thought that both approaches contradict each other and so could not be used together. However, like writing software you combine best practices from different methodologies that meet your project requirements, improving the chances of a successful project.

I'm not going to try and pretend to be a TOGAF professional, I have an awareness of the framework and have never used it end to end. I believe that if you are going to design software then you should at least be aware of frameworks such as TOGAF and alternatives. A good start on agile is Martin Fowler "The New Methodology" and "Can SOA be done with an agile approach".

TOGAF combined with Zachman framework is a top down design methodology and provides an excellent mechanism for eliciting requirements and providing a framework for communication in a common language, but as Fowler states big up front design can become very expensive. Also, it can lead a project to not deliver what is required by the business when the system goes live, rather it delivers what was required initially. The difference may well be dramatic.

A good reason for top down design is to do with procurement and the need to identify appropriate commercial products to use, a focus of TOGAF. Large organisations want to outsource at fixed price and the vendor organisation doing the work wants all the details up front to have the best chance of delivering the project at a profit. Again, Fowler makes a good point about the "Adaptive Customer" and how customers need to be adaptive in the way they engage with vendors. Although from my experience of being both the vendor and using vendors to do work there is never an ideal approach. A vendor wants to make as much money as possible while the customer wants to control the scope and spend as little as possible.

So where do you want to spend your money?

Up front with lots of design, then on lots of change requests and the end result will be lots of documentation that in theory should reduce the maintenance overheads, keeping the future costs down.

The alternative is relying upon highly skilled and talented  software engineers who may or may not use a silver bullet, document the code or write any design material thus making maintenance harder for someone un-familiar with the code.

I have seen both top down and bottom up methodologies succeed and fail to varying degrees. It is my opinion that success is based upon good judgement and adaptability at the beginning and during the project on the part of everyone involved.

Combining the requirement analysis and control features of TOGAF with an Agile methodology, and the use of PRINCE project management looks like a good combination as long as you are adaptable in selecting the parts that make most sense for the project you are working on.

Fire people who think they're entitled to run things

I recently had a conversation about how I would handle a situation where someone was not willing to comply with corporate policy or was unwilling to work as part of a team. My immediate reaction was to say "fire them" (which is rather brutal), and even during the conversation I had to explain that this would be the final resort.

Disruptive Influence

Having had time to think about the question I now believe there are stages before reaching the formal dismissal process. I feel the reason for getting to the point of firing someone should only be based upon the team and organisation as a whole. If the team can't get on with them, or the person(s) is disruptive to the success of a project or organisation. This is summarised really well in an article by Ben Leichtling "Fire people who think they're entitled to run things". A manager or senior professional in an organisation has a responsibility to deliver projects to a high standard, if someone makes that hard to achieve then there is a serious problem. The disruptive influence of some team members can make it really hard for a manager to deliver a successful project, or to feel in control of the project.

Personally I would try to work with the person by understanding what motivates them and explaining why it is important to work as a team and within the guidelines set out by the organisation. There is also the case that they may have valid arguments for doing things differently and are not communicating them effectively. In the end someone has to be in charge and people have to accept authority so if all else fails you have to embark upon the path of dismissal.

Luckily, I've never been in the position of working with really obstructive people and where issues have occurred it has been possible to resolve them through compromise or if necessary through being assertive. Although occasionally I'd love to say "Look if you don't like it then find a new job", but that is hardly professional. I'd prefer to maintain the moral high ground.

Constructive Influence

There is an alternative to the disruptive influence and I have used this successfully with like minded colleagues. This alternative is to use constructive and critical analysis. Putting a lot of clever and experienced IT people into a room can lead to a conflict of ego's. Each person is bound to have an opinion about how to design a solution or deliver a project, and may think theirs is the best solution. The challenge is to make use of all of the different ideas to perform critical analysis. Somone coming into a design meeting using critical analysis after it has started may believe the team is in conflict and not achieving anything because of some of the heated debates that can take place.

Critical analysis will only work well if everyone understands it is taking place and can be professional in accepting other peoples views and constructively analysing them. Eventually the best parts of each idea will start to come together until it is possible to arrive at a solution using the best of the ideas.

The key to success is that someone has to be in charge and have the authority to make the hard decision of intervening at the right moment to influence the design, and to stop the process when it is taking too long or the best possible solution in the time available has been delivered.

Team Success

I don't claim to be an expert on the psychology of teams but I do have a lot of experience of managing very capable IT teams. From my experience I can conclude team success can only be achieved if everyone works together and accepts that there is a structure. Sometimes managers have to earn respect and in the worst case they have to take firm action to ensure success.

The bottom line is that a manager can "fire" someone working for them, it never works the other way around. So even if a team member thinks the manager is wrong, it is down to a professional team member to influence the senior person so that the correct approach is used.

Project estimation (duration, effort) and Project Failure

Several times recently I've been involved in discussions about project estimation, sometimes with project managers and other times in general conversation about project failure. Here is my opinion on why both duration and effort are important in estimation and neither can be ignored. This my personal opinion and every project and organisation may differ and should be treated appropriately by using the correct project management and software design methods.

Background on Project Failure

The UK National Audit Office summarises the common causes of project failure as:

NAO/OGC Common causes of project failure

1. Lack of clear link between the project and the organisation's key strategic priorities, including agreed measures of success.

2. Lack of clear senior management and ministerial ownership and leadership.

3. Lack of effective engagement with stakeholders.

4. Lack of skills and proven approach to project management and risk management.

5. Lack of understanding of and contact with the supply industry at senior levels in the organisation.

6. Evaluation of proposals driven by initial price rather than long term value for money (especially securing delivery of business benefits).

7. Too little attention to breaking development and implementation into manageable steps.

8. Inadequate resources and skills to deliver the total delivery portfolio.

I define project failure as one that either goes over budget, over schedule or both, or fails to deliver what the stakeholders actually expected. Most media attention focuses upon costs and timescale, and let's face it project failure is not isolated to IT projects - Wembly Stadium, 2012 Olympic Bid, the Millennium Dome were not IT projects. Until recently Heathrow Terminal 5 was hyped as the way to run projects (Agile), yes it may have been on time and on budget but in the end it failed to meet stakeholder expectations – the users of the terminal were far from happy and executives lost their jobs.

The importance of duration and effort in estimation

When I ask for estimates I always ask for two numbers the duration and effort – just so that it is clear to me how much the work is costing and how long it will take to deliver. When it's an external contractor I'm interested in duration and the bottom line cost not the effort, so this note applies to internal projects.

Effort is the direct cost of running the project and I would expect a project manager to be able to break down the estimate into deliverables/artifacts/tasks/function points – for me they are all the same, a quantifiable item of work. The quantifiable item of work can be listed in a Scrum burn-down list or an item in a project plan, but the project plan and burn-down need to take into account duration, more on this later. This effort provides the basis for future estimation for performing the same or similar piece of work. Using a well managed timesheet system enables project managers to make better estimates for future projects based upon projects of similar size, complexity, and industry type (OK it's not quite that simple but I'm not writing a thesis here).

The effort estimate will be affected by a number of factors e.g. sick, holiday, training, going to meetings not related to the project. All the daily tasks that an employee will be expected to undertake. This is what makes up the duration estimate of the project – the bottom line is "how productive is a person each day in your organisation". So if the effort to complete a project is 100 man days but an employee can only spend 80% of their time doing productive work then the duration is 120 125 days to deliver the project.
(UPDATE - Oops. Basic math error, should be 125 days.)

Estimating duration and effort means that a project can meet schedule and costs, but accurate estimation is only possible with historic data – which is why using accurate timesheet systems is needed.

Most people in software hate completing timesheets. I know this because I did when I used to cut code – it's an unnecessary distraction and stops you getting on with doing fun things like designing and writing software.

If there is to be any professionalism in software engineering then developers and testers etc need to understand the importance of estimation. The problem is that every time a developer enters 8 hours development time when they really worked 12 just sets false expectations for the project manager and stakeholders. The next time a project is estimated the project manager looks at the timesheets and thinks "if I pay for 2 hours overtime I can get more from my team" and the team end up working 14+ hour days. OK, nobody wants this and I firmly believe in the Agile 8 hour days – even if I don't apply what I preach, but the responsibility lies with everyone on a project to ensure effective project estimation.

Applying the appropriate estimation

At Altio PRINCE and Agile (Scrum) techniques are used to deliver projects. PRINCE provides the control and communication, the use of burn-down charts and daily meetings ensure project duration and deliverables are constantly monitored.

Effort estimates are used to calculate cost and this is where it is important that staff book their time accurately otherwise a project can fail on cost because staff spent most of their time on work that was not project related and so should have booked their time accurately (and I do draw the line at having a "Rest Room" or "Cigarette Break" task). For Altio projects we use several estimation technique – the simplest being a spreadsheet that applies triangulation estimation using best, most likely and worst case scenarios.

A project manager then takes the estimated effort and populates a project plan with tasks and adjusts staff availability to get a duration.

To monitor a project in progress then duration is important and using burn-down charts with staff providing daily estimates of how long it will take to deliver being the key. This estimate by the team members is pure duration, if the person is only managing to work 2 hours a day and there is 10 hours of work left, then the duration is 5 days. It's down to the project manager to manage why the person is only doing 2 hours a day and to manage the risks that this dilution of work effort causes.

Constantly changing estimates

It is important to constantly review project in progress and adjust estimates based upon knowledge from previous projects and deliveries. Using PRINCE gateways as the time to re-estimate is important, as it is the time to provide the details to the stakeholders for them to make decisions.

Conclusion

There are lots of debates online about project estimation and ultimately every project will be different because of the people working on it, the technology being used and the expectations of the stakeholders.

Software projects are all about developing new and innovative systems otherwise we would just buy the most appropriate product off the shelf. This means there is no blue print for accurate software estimation – software engineers are not laying bricks to build a house so there is no way to say how many bricks per hour a person can lay and apply that to all projects (the analogy being lines of code = bricks).

REFERENCES

Listed below are a number of useful links and documents that I use for reference.

1. http://www.itprojectestimation.com/estrefs.htm
   
2. The Holy Grail of project management success, http://www.bcs.org/server.php?show=ConWebDoc.8418 accessed March 2007
   
3. Wembley Stadium Project Management, http://www.bcs.org/server.php?show=ConWebDoc.3587, accessed March 2007
   
4. Olympic bid estimates, http://www.telegraph.co.uk/sport/main.jhtml?xml=/sport/2007/02/08/solond08.xml, accessed March 2007
   
5. UK Government PostNote on NHS Project Failure, http://www.parliament.uk/documents/upload/POSTpn214.pdf, access March 2007
   
6. UK Government Post Note on IT Project Failures, http://www.parliament.uk/post/pn200.pdf, accessed March 2007
   
7. Project Failure down to lack of quality, http://www.bcs.org/server.php?show=ConWebDoc.9875 , accessed March 2007
   
8. Steve McConnell, Rapid Development, Microsoft Press,1996
   
9. Martyn Ould, Managing Software Quality and Business Risk, Wiley,1999
   
10. Art, Science and Software Engineering, http://www.construx.com/Page.aspx?hid=1202 , Accessed October 2006
    
11. Simple and sophisticated is the recipe for Marks' success, Project Manager Today, page 4, March 2007
    
12. Ian Sommerville, Software Engineering 8^th Edition, Addison Wesley, 2007
    
13. Barbara C. McNurlin & Ralph H. Sprague, Information Systems Management in Practice 7^th Edition, Pearson, 2004
    
14. Overview of Prince 2, http://www.ogc.gov.uk/methods_prince_2.asp, Accessed November 2006
    
15. The New Methodology, http://www.martinfowler.com/articles/newMethodology.html, Accessed October 2006
    
16. The Register – IT Project Failure is Rampant http://www.theregister.co.uk/2002/11/26/it_project_failure_is_rampant/, accessed October 2006
    
17. Computing Magazine – Buck Passing Route of Project Downtime http://www.computing.co.uk/itweek/news/2183855/buck-passing-root-downtime, accessed February 2007
    
18. National Audit Office – Delivering Successful IT Projects http://www.nao.org.uk/publications/nao_reports/06-07/060733es.htm, accessed March 2007
    
19. Successful IT: Modernising Government in Action, UK Cabinet Office, page 21
    
20. Project success: the contribution of the project manager, Project Manager Today, page 10, March 2007
    
21. Project success: success factors, Project Manager Today, page 14, February 2007
    
22. Six Sigma Estimation http://software.isixsigma.com/library/content/c030514a.asp , accessed October 2006
    
23. Analogy estimation http://www-128.ibm.com/developerworks/rational/library/4772.html, accessed January 2007
    
24. Symons MKII Function Point Estimation http://www.measuresw.com/services/tools/fsm_mk2.html, accessed March 2007
    
25. COCOMO estimation http://sunset.usc.edu/research/COCOMOII/ accessed January 2007
    

End of January beginning of February

Boy, how time flies, I can't believe it's the middle of February already and the year is moving fast. The team working on Altio have released Altio 5.1.4 which is probably the last release of Altio 5.1 before we release Altio 5.2. Just to make me even busier I spent the first week of February in Boston initiating our latest project for Paragon using PRINCE project management and building a system using Altio with a SOA architecture.

The project kick off in Boston went really well with the documentation being received extremely well so now all involved in the project know about:

• the vision
• the objectives
• delivery gateways
• quality plans
• project tolerances
• staff involved

All because we have a Project Initiation Document (PID), which while it was hard work to produce I hope will provide value through the project lifecycle by ensuring the project is delivered on budget and on time.

Some in the teams are horrified at the amount of documentation we are producing to start our new projects, while we're all keen to do PRINCE project management now it is understood I feel I have a lot of pressure for it to succedd as it's my idea.

Why is the organization adopting a formal project management technique? Well it's because we want to provide effective communication to all stockholders in projects and to remove as much ambiguity and as many assumptions as possible that are typically made at the beginning of the project.

For the people doing the clever work of writing code and delivery functionality there will be little change, we will continue to use Agile methodologies.

In the end it means people in the company can continue laugh about my Burndown charts as well as now laughing about delivery Gateways. Ultimately the quality of our software is improving along with the ability to better predict the delivery dates of our projects and if testers and developers morale is kept high by laughing at me I can't complain :-) .

While the project will be a major challenge everyone is keen to see it succeed as it brings together everything Altio is about, a graphically rich and interactive front end with a Service Oriented Architecture (SOA) at the back-end. When Altio 5.2 is released (due May) users will have the ability to make use of Altio's data mashups as well as screen mashups - we aim to really challenge the idea of what makes a RIA and set the benchmark high.

So Altio 5.2 is well on it's way to being delivered in May and will bring a whole new designer and set of controls... I will add more on this in a later entry.