Last week saw the launch of Squbes onto the Google Play store. Something to celebrate – but it was nearly a month overdue – and the iOS release was a week later. So what went wrong and why do software projects overrun?
Underestimating complexity
When estimating how long a software project will take to deliver, we rely on past experience to gauge the complexity and hence time needed for individual tasks. A smart developer then adds a factor to this to give a margin. My experience with this is that I generally get complex tasks about right. I’m much more likely, however, to underestimate simple tasks. There are a whole raft of small jobs which we either think will be easy, or completely fail to factor in as they’re so trivial we don’t even notice them, only to find when we come to implement them that they either don’t work as advertised, have changed since we last did them or they introduce side effects into other parts of the project that we had not anticipated.
For Squbes, I had always assumed that the game mechanics were the complicated part. In reality they proved relatively straight-forward to implement. The bits that took much longer were things like the ads and in-app purchases. As these are standard across many projects I assumed that they would be well document with easy to follow examples. Unfortunately my use-case seems to be a minority one and they are both already complex solutions. Flutter layouts also provided some entertaining moments as I found that coping with lots of different screen sizes and aspect ratio changes was not as easy as I had expected it would be. Lots of small issues can add up to significant delays.
Scope Creep
A second major cause of delays is scope creep. This is common on longer projects where the changing requirements of the real world mean requirements keep being added late into a development cycle. With agile approaches (delivering small chunks of functionality often) the effects of this can be managed much more easily than with traditional methods. The problem is, however, even small requirement changes can have a significant impact on existing code. The new code may be easy – but changing the architecture of everything that had gone before can be time-consuming.
With Squbes I made the mistake of dropping a requirement which I thought it added too much complexity only to add it back in with a few days to deliver because my play-testing showed the game was too simple without it. A fair chunk of existing code needed to be reworked and retested to accommodate this. In the end it didn’t add a huge amount to the overall project, but it definitely was a contributory factor.
My complex new routine actually worked first time completely correctly – but it didn’t look like it was working because there was a subtle bug in thoroughly tested existing code which had never been called in quite that particular way before just waiting to trip me up!
Unrelated activities
Halfway through the development, things were going so well that I stupidly took on another project. This was a bad move as it meant that a full month of development time was spent not working on Squbes at all. What was worse (you’ve guessed it) the other project also overran and the knock-on was inescapable.
As an IT Manager this was always one of my worst nightmares. Unrelated activities normally start as a minor but unrefusable request from a senior manager, and the result is to take one or two of your key project workers off the main project at a critical juncture.
External Dependancies
Back in the day when I worked in large organisations the biggest single factors, however, arose from unmanaged external dependancies. These often start with delays from the client departments. Yes they are eager to get their projects delivered, but they seldom realise the importance of managing their own part in that. Signing off requirements and design documents late gets the project off on the wrong foot and can be difficult to recover from. External dependancies also come in many other forms – and the trick is to minimise and manage them as best you can.
One my biggest gripes with mobile development is how dependant you are on black boxes from other suppliers. Android Studio uses a system called Gradle to manage its build process. When it works you don’t notice it. Often, however, when you upgrade something you need to move to a newer version of Gradle and then all hell breaks loose. It is nothing whatsoever to do with your project, but until you find and fix its gremlins you cannot build or run your code. Software updates are a nightmare to be avoided as much as possible during a short project but then, in order to release to the latest version, all of that pain is stored up for the end. Just at the point when you are already running close to the deadline.
When I started writing this article I was waiting for a 7Gb download from XCode because (get this) Apple have changed the screen shot size requirements for the Apple Store. In order to generate a compliant iPad screen shot I needed a new version of the iOS emulator which is only available in the most recent version of XCode. I kid you not. The code works. The pictures are beautiful. But StackOverflow is chock full of questions from down the years as to how to generate screenshots for store displays that Apple will actually accept. It should not be this hard.
Compliance
Another factor which has been getting steadily worse over the years has been the need for compliance. It didn’t used to be something that I ever factored in to an estimation process until a couple of years back. Now, however, you know that there is going to be a delay releasing onto the app store as some unknown tester checks your project is up to scratch for delivery.
The number of documents you need to write, and policies you need to review, sign and wait for authorisation for, is growing all of the time. For my current project I needed to complete compliance information (much of it duplicated) in four separate Google systems and two Apple systems (so far). I lost several days in waiting for specialist support from my bank and Apple because for some reason Apple refuse to recognise the perfectly valid format of my account code. I’ve lost count of the number of text messages that I have waited for as two factor authentication as I attempted to prove that I am who I say I am and I do have the right to use that email, this phone number, that website, that bank account etc and so forth.
Large organisations have legal teams to deal with all of this – for the single man team the number of trades you need to be a jack of is increasing by the year. Sadly compliance is a factor which is only set to get more complex and will doubtless be the cause of many projects running late.
Release
Once the App has been submitted to the app stores – the timing is out of your hands. Amazingly this stage seems to be faster now than it used to be which is a welcome change. I’m pleased that both Google and Apple accepted the app first time with minimal delay. Late or not, it is always satisfying to see something that you coded out in the wild…
Leave a Reply