One of my pet hates is Project Managers (PM's) living their lives in Gantt charts or spreadsheets. I've seen many projects over the years where PM's have got to the end of the project without ever seeing the actual delivered software! Incredible I know. I'm flabbergasted every time I see it and I still see it regularly. In fact, I think it's on the increase.
They usually get their progress reports from developers via MS Excel in the form of hours to complete per task or some other kind of subjective guess. They then merrily update their Gantts in complete ignorance of what's really happening and get on with writing their progress reports. It's a real coincidence that the plans nearly always look rosy in these situations ;)
On some occasions I've had to force PM's to look at the software to gauge for themselves how complete it is. Interestingly enough, what they consider complete rarely matches the developers idea of complete, which in itself introduces another key review point.
My message to PM's is, stop hiding behind project plans and get under the skin of the software to form your own judgement of progress.
My message to developers is, the only real measure of progress is tangible software that PM's can see and interact with, so make sure you're constantly in a position to demonstrate this.
Thursday, 5 July 2007
Tuesday, 3 July 2007
An easy way to improve code quality
Cyclomatic Complexity has been around for a long time and yet many developers are still unaware of it. Cyclomatic Complexity is the measure of code complexity. It's just one aspect of code quality but I've found it's impact to be massive when used daily within the software development life cycle. Cyclomatic Complexity Analysis basically counts the number of decision points (e.g. If's, elseif's, Case's, nesting levels, etc) in source code and gives you a rating. These ratings can be assessed as follows:
The reality is that the most complex areas of a code base attract the most bugs and as it's complex code it's harder to fix (and costs more!).
About 3 months ago I introduced it into the daily build on all projects at my company so that the build fails if code is introduced into the build with a complexity rating greater than 15. Initially it took a while for the development team (34 developers) to make it part of their daily routine but it has paid massive dividends. We've noticed a sharp decrease in the number of bugs found in the testing phase, and maintenance of the code base's have eased dramatically.
If a developer can't get the complexity down below 15 then it's put out for review to other developers. There are occasions when it's truly not possible to reduce the complexity due to performance tradeoffs but at least those important decisions are being handled in the correct manor.
Out of curiosity I ran the analysis tool over some past projects to get a feel for some kind of baseline to measure improvements against. One particular project reported a maximum complexity of 536!! I thought the analysis tool was broken until I dove into the source code and found a single method containing over 3000 lines of code, consisting mainly of if, elseif, if, elseif, etc. Also, the deepest level of nesting in this method was 24! Only a complete nutter could have written this!
So in summary, my advice to you as a developer is anything you write, analyse the complexity and simplify accordingly.
There are many other tools available for analysing code complexity such as IDE integrated plugins from Developer Express to name just one. Find the one that's right for you and use it.
The best tool I found for analysing complexity is Source Monitor. It's good for two reasons; you can run it as part of your daily build & smoke test, and it's free! It works with all the mainstream languages such as C#, VB.NET, Java, and we've also managed to get it to work with Actionscript 2.0.
| Cyclomatic Complexity | Risk Evaluation |
| 1-10 | a simple program, without much risk |
| 11-20 | more complex, moderate risk |
| 21-50 | complex, high risk program |
| greater than 50 | untestable program (very high risk) |
The reality is that the most complex areas of a code base attract the most bugs and as it's complex code it's harder to fix (and costs more!).
About 3 months ago I introduced it into the daily build on all projects at my company so that the build fails if code is introduced into the build with a complexity rating greater than 15. Initially it took a while for the development team (34 developers) to make it part of their daily routine but it has paid massive dividends. We've noticed a sharp decrease in the number of bugs found in the testing phase, and maintenance of the code base's have eased dramatically.
If a developer can't get the complexity down below 15 then it's put out for review to other developers. There are occasions when it's truly not possible to reduce the complexity due to performance tradeoffs but at least those important decisions are being handled in the correct manor.
Out of curiosity I ran the analysis tool over some past projects to get a feel for some kind of baseline to measure improvements against. One particular project reported a maximum complexity of 536!! I thought the analysis tool was broken until I dove into the source code and found a single method containing over 3000 lines of code, consisting mainly of if, elseif, if, elseif, etc. Also, the deepest level of nesting in this method was 24! Only a complete nutter could have written this!
So in summary, my advice to you as a developer is anything you write, analyse the complexity and simplify accordingly.
There are many other tools available for analysing code complexity such as IDE integrated plugins from Developer Express to name just one. Find the one that's right for you and use it.
The best tool I found for analysing complexity is Source Monitor. It's good for two reasons; you can run it as part of your daily build & smoke test, and it's free! It works with all the mainstream languages such as C#, VB.NET, Java, and we've also managed to get it to work with Actionscript 2.0.
Sunday, 1 July 2007
Agile - here's my two pennies worth
Not a week goes by without hearing someone say "we're taking an Agile approach to this project". In most cases, the Agile approach means "we're making it up as we go along". I'm not going to create yet another blog on the pros and cons of Agile. Instead I'm simply going to point you in the direction of a great video presented by the inventor of SCRUM, who let's face it, should be able to explain it better than anyone.
Even if you can't adopt the full SCRUM approach you should still be able to pick out a few gems from this video. Developers should pay particular attention to the section on cutting quality!
Even if you can't adopt the full SCRUM approach you should still be able to pick out a few gems from this video. Developers should pay particular attention to the section on cutting quality!
Friday, 29 June 2007
Solutioneering
When I’m recruiting developers, what I’m actually looking for is Solutioneers. These are developers who consider “getting things done” as one of the problems they need to solve. For example, if another part of the project team is holding up their work, this isn’t an opportunity to kick back and grab some slack time. This is a problem that needs solving. May be the simply solution here would be to walk around the office and get the blockage cleared. I here non-solutioneers saying “but that’s not my job” or “I didn’t want to step on anyones toes”. Finishing a project on time must be a Solutioneers primary goal and as such is always willing to "solve this problem" by rolling up their sleaves and getting stuck into any aspect of the project. Solutioneers take ownership very seriously and often lose sleep at night over particular aspects of project delivery.
To be dynamic enough to solve problems they need to keep on top of what’s happening around the industry, and constantly pushing their own intellectual capacity and technical abilities. These Solutioneers are avid bloggers who not only write blogs but also see blogs as a valuable source of knowledge. They spend their daily commute glued to technology podcasts and spend lunchtimes scouring the web for quicker and better ways of developing software (these are the guys who keep sending emails saying, “hey, have you seen this!”). Almost certainly they'll have what is approaching an enterprise class data centre in their home to enable them to tinker in the evenings and weekends. Solutioneers posses an almost unhealthy passion for software development and never rest on projects until they’re over the finish line, so a sense of urgency is one other facet here.
You may be thinking that outright Solutioneering can be very hazardous in a commercial project environment and spits of perfectionism which can easily blow project budgets (over engineering syndrome or paralyses by analysis!). This is yet another problem for a Solutioneer to overcome. Solutioneers are experienced enough to make a balanced call on trade-offs, i.e. I know the purest approach to a software problem, I know the quick and dirty approach, but what’s the risks associated with trade-offs from either end of the scale?
Solutioneers have to be good communicators and be very personable, friendly, and approachable. But most of all they must posses a good sense of humour.
Oh yes, I forgot, and if they know the .Net Framework, C#, SQL, and most Microsoft technologies and platforms then that also helps! ;)
To be dynamic enough to solve problems they need to keep on top of what’s happening around the industry, and constantly pushing their own intellectual capacity and technical abilities. These Solutioneers are avid bloggers who not only write blogs but also see blogs as a valuable source of knowledge. They spend their daily commute glued to technology podcasts and spend lunchtimes scouring the web for quicker and better ways of developing software (these are the guys who keep sending emails saying, “hey, have you seen this!”). Almost certainly they'll have what is approaching an enterprise class data centre in their home to enable them to tinker in the evenings and weekends. Solutioneers posses an almost unhealthy passion for software development and never rest on projects until they’re over the finish line, so a sense of urgency is one other facet here.
You may be thinking that outright Solutioneering can be very hazardous in a commercial project environment and spits of perfectionism which can easily blow project budgets (over engineering syndrome or paralyses by analysis!). This is yet another problem for a Solutioneer to overcome. Solutioneers are experienced enough to make a balanced call on trade-offs, i.e. I know the purest approach to a software problem, I know the quick and dirty approach, but what’s the risks associated with trade-offs from either end of the scale?
Solutioneers have to be good communicators and be very personable, friendly, and approachable. But most of all they must posses a good sense of humour.
Oh yes, I forgot, and if they know the .Net Framework, C#, SQL, and most Microsoft technologies and platforms then that also helps! ;)
The importance of defining non-functional requirements
You wouldn't believe the amount of projects I've come across where nobody on the project team has established what the non-functional requirements (NFR's) are. If you're reading this and thinking "what the hell are non-functional requirements" then this very brief introduction to them is for you. If you're already familiar with NFR's then read on anyway as there may be a few nuggets in here for you that you don't already know.
So, non-functional requirements (sometimes referred to as Software Quality Attributes), in the simplest terms define performance, scalability, capacity, resilience, and many more attributes of the software being delivered. The best way for me to describe why NFR's are so important is to share with you a few experiences. Here's one experience to demonstrate the point:
So, non-functional requirements (sometimes referred to as Software Quality Attributes), in the simplest terms define performance, scalability, capacity, resilience, and many more attributes of the software being delivered. The best way for me to describe why NFR's are so important is to share with you a few experiences. Here's one experience to demonstrate the point:
A web application is designed, built, tested, passes UAT, and deployed. The customer is happy for the first 6 months as traffic levels have been low. Over time the traffic levels rise (from 30 user sessions a day, to over 2000 sessions a day). The web site starts to crash regularly, the customer is very unhappy with the "quality" of the delivered software and wants it fixing. Well, you can see where this is going already. The answer to this seems obvious, why didn't the supplier agree traffic levels with the customer up front and design the solution appropriately?
Well, this isn't always as easy as this. Did the customer even anticipate such high traffic levels? Is the customer techno savvy enough to care about such things as this is what they pay you for isn't it? Shouldn't you have made some assumptions in this case?
When I'm dealing with a customer who isn't techno savvy and doesn't know what their traffic levels are going to be, there's always the temptation to design for a large number of users, i.e. design BIG. Unfortunately, going large on these decisions costs more money to do and very quickly you become uncompetitive and could potentially end up with the customer walking away and cancelling the project before it's even started. The best thing to do in these circumstances is to agree with the customer an affordable level of scalability and then warrant the system to this level. Basically, agree that your design can handle say 100 concurrent sessions, and do your internal performance testing to this level. In this situation you're only warranting the system to 100 sessions and if the customer exceeds these limits then the solution may continue to operate comfortably but you won't fix any issues that occur without charging for it.
For further reading on the subject of NFR's here's a link to an extremely thorough list of NFR's that I use daily! Volere Requirements Specification Template
Subscribe to:
Posts (Atom)
