Code reviews har længe været en integreret del af udviklingsprocessen, men væsentligt mere sjældent bliver en sikkerhedsanalyse inkluderet som en
Three Classic Software Challenges Revisited. Price: 500 mio DKK
After 10 years in the making, the Danish Government gave up on a new national system for the police last year.
Three Classic Software Challenges
Working with software development and project management on a daily basis, three issues stand out. These are classics in software development, and hold universal challenges, which we all face time and time again.
In the last segment of this post, I revisit three classic software principles whose necessity shines through in retrospect of the costly affair.
First, three issues pointed out by Rigsrevisionen, that I find especially important for our industry.
1. INSUFFICIENT COMMUNICATION
Rigsrevisionen points out the failed assumption that the police system could have been effectively based on a standard system for electronic handling of cases and documents. This misunderstanding was a result of insufficient communication between the police and the system supplier.
The report criticizes the police for not having transferred the necessary knowledge about the domain and the police’s ways of working to the system supplier. The insufficient communication lead to a large amount of unexpected tailored development, which was both expensive and time-consuming.
2. IGNORING USABILITY ERRORS
Another interesting issue stressed by Rigsrevisionen is that the initial system was pilot tested without a prior usability test. The problem of course being that usability tests are important, and that it is important that they are distinguished from pilot tests.
Rigsrevisionen emphasizes that the lack of usability tests caused an ineffective pilot test: The police officers that tested the system had no chance of carrying out their daily work with a system containing numerous usability errors. This affected the pilot test badly as the usability errors took focus and acted as a barrier for authentic usage
3. INSUFFICIENT PROJECT MANAGEMENT
Finally, the report accentuates that project management was weak, especially lacking in diligence and explicitness. It is pointed out that management of the project economy was insufficient, and that the documentation of key decisions and their rationale were absent.
The report stresses that in projects of this magnitude, timespan and complexity, status reports, continuous tracking of economy and hours spent etc. is of upmost importance. If these are missed, the project can not be completed in a successful manner.
Lessons Learned: The Privilege of Hindsight
As Kirkegaard said, “Life can only be understood backwards; but it must be lived forwards”. Clearly, the famous Danish philosopher was not thinking about IT projects, but his observation is applicable.
It is easy to see what should have been done, when you look back on a project. And much harder to make the right decisions in time while it’s happening.
Here are three well-known software rules highlighted and relearned by the costly affair:
1. Insist on understanding the client’s domain thoroughly and early. Understand how and why the system is needed by doing your research and asking the right questions – it’s crucial in order to deliver a system that does what it is supposed to.
2. Use usability tests to identify and eliminate usability errors before pilot testing.
Usability tests may seem costly at first but are a valuable investment in the long run. Furthermore, users are busy people and they should be treated respectfully when being involved in pilot tests.
3. Define an appropriate level of project management and stick to it.
Balance your project management with the project characteristics. Once found, document it and its reasons. This enables you to stick to your plan, or if necessary, knowingly correct it in accordance with the plan.