Thoughts on software development.
When everything is going wrong and you’re spending most of your day putting out fires on projects, it’s easy to think project management is more art than science.
If you want to improve the chances of success in your projects, this list of ten common problems is well worth considering – covering everything from organisational culture to improper management of risk.
Every year, the SANS Institute and Mitre compile the Top 25 Most Dangerous Software Errors list – a collection of the most widespread and critical errors that lead to serious vulnerabilities in software. The list is published annually to help raise awareness in the software development industry, and is used by programmers, end-users, and researchers in an attempt to avoid the most common mistakes and build more secure software.
The list is quite technical, but eye-opening and highly informative, and includes a ‘Monster mitigations’ section with effective suggestions for eliminating or reducing the severity of the top 25 errors and more besides.
The V-model is widely acknowledged as the industry’s standard testing model; but is this down to it being the best approach, or has the V-model simply evolved to become a de-facto standard?
In this interesting article, James Christie looks at the “dangerous and seductive V-model”, and helps to explain its flaws (rooted in a basis on the traditional Waterfall), as well as offering some workarounds such as the W-model, the Butterfly model, or the adoption of a more iterative, Agile approach.
Read the article in full on James’s site – ClaroTesting.com.
One of the quickest and easiest metrics to introduce into an existing test system is Root Cause Analysis. It’s also one of the most powerful, with the potential to radically improve the whole development lifecycle if properly implemented.
If you use a good incident management tool, adding RCA to your incident management process is as easy as adding a mandatory field to the incident form. Very little overhead is introduced – when an incident needs to be closed, the only extra work required is to specify the root cause from a pre-defined list, and perhaps add a note for extra information if required.
Continue reading
It is easy for technologists to forget that the business should be responsible for making the decision whether or not to release software.
Being involved in the design, development, and testing of a piece of software leads us IT folks to believe we know the product intimately, and are therefore best placed to determine its fitness for purpose; but external factors such as the cost of not implementing mean this isn’t always the case.
In this post, Michael Bolton reminds us how the decision to release is not merely a technical one, and offers some advice to product owners as to when they should ship their product. The simple answer is: when you’re no longer so nervous you don’t want to ship.
