This is the extended abstract of my dissertation for module T802, which is the final module of my Open University Master of Science degree in Technology Management. It was a tough module, spanning just over 12 months (including preliminary research), but at the same time was very rewarding. Background Software is becoming increasingly common in …
Developer Anarchy
The latest episode of Software Engineering Radio contains an interesting discussion about a project management technique known as Developer Anarchy. Fred George, the interviewee, defines anarchy as a group of people managing themselves, with few or no rules being imposed by higher levels of management. George describes how he first discovered this technique when working …
On organisational structure and software architecture
Organisational structure In his 1975 book, The Mythical Man-Month, Fred Brooks claimed that adding more people to a late software project would make it even later. His reasoning behind this claim, which has now become known as Brooks’ Law, was that people in a team need to communicate with each other. As the team grows …
Continue reading “On organisational structure and software architecture”
Daily stand-up meetings: A communications pattern and anti-pattern
The pattern I like the idea of holding a daily stand-up meeting. This involves a team coming together at the start of each day to provide brief status updates and discuss the challenges ahead. I see stand-ups as being particularly useful in helping to resolve issues that are blocking progress, such as in this fictional …
Continue reading “Daily stand-up meetings: A communications pattern and anti-pattern”
Mobile apps (Oops, something went wrong…)
A personal perspective The first time I came across an error message telling me “oops, something has gone wrong…” was when I installed the LinkedIn app on my Windows Phone back in 2013. After a little research, I discovered that what this particularly unhelpful message was trying to tell me was that the time on …
Continue reading “Mobile apps (Oops, something went wrong…)”
Good luck, and watch out for bugs!
The latest issue of The Embedded Muse contains the following quote regarding the use of the term “bug” by software developers: We could, for instance, begin with cleaning up our language by no longer calling a bug “a bug” but by calling it an error. It is much more honest because it squarely puts the blame where …
An introduction to software product line engineering
This article is based on examinable work that I submitted for the postgraduate Open University module M813 – Software Development. Software components With the end of the 19th century came the introduction of the now ubiquitous form of transportation that is the automobile. Early models were mostly hand crafted by skilled operators and priced accordingly, which …
Continue reading “An introduction to software product line engineering”
Software project failure rates
In order for a project to be classified as successful, it must satisfy three criteria: its outputs must be of the agreed quality, they must be delivered in the agreed timescale, and they must be delivered at the agreed price. The two studies below show that around a quarter of the software projects involved failed catastrophically (i.e. cancelled or delivered …
The roundup – week 50
A summary of three online articles that I have found interesting in the past week. The benefits of peer review In this article, Jack Ganssle sings the praises of code inspections; citing one study which claims that such inspections are ten to 34 times cheaper than testing. A second study is also cited, which claims that …
No comprende the non-functional requirements: Part 2
In a previous post I discussed my difficulty in understanding the concept of non-functional requirements and how I planned to attend a lecture on the subject provided by my local branch of the Chartered Institute for IT. Having now sat through this lecture, I am relieved to know that I was not alone in my confusion; and overjoyed that the concept …
Continue reading “No comprende the non-functional requirements: Part 2”