data scientist and machine learning engineer
This blog post will cover planning successful timelines for medium-size projects.
It is common to be asked before starting an iOS app project to estimate how much time the development will take. Here is my process to think about that.
I initially make a 'features-only time estimate'. I do this by adding the time required for the major components that are part of the app. Here are the components I see in almost every other app: type of architecture , UI, networking and connection with database, outside libraries to be imported that do specific things and understanding their API, functionalities that are core and differentiate the app (for example: a screen that does manipulation of 3d objects or a screen that adds photo effects while taking a live photo), specific proprietary algorithms that the app backend has that add value by computing specific things and the developer has to construct (for example: optimise matching a user with another user via certain factors), social, payments, notifications, animations.
Once I add the time for these components, which is constant for most of them since I have done them before, I have the 'features-only time estimate' to develop the app.
But I noticed there are three major categories that add time to this partial estimate:
Adds onother 20% of time: Making the app adaptive on different sizes for both iPad and iPhone. This is time consuming because not everything can be done in Storyboards. For example, fonts and spacings (width and height behave differently) between elements have to be added in code. The specific value of each has to be initially calibrated by running in the simulator and tested on multiple screen sizes. Depending on the speed of the computer this is faster of slower. This is done for every screen, for each element added.
Another 20%: Mirco decisions on architecture - the lots of small decisions to be made in an app that a designer does not see, and each needs code written. I include here all the edge cases for the different functionalities. For example, what happens when I have a slideshow and I reach the last picture and the user still swipes?. Adding inside the app the multitude of situations only a tester might uncover takes time to think about and test.
Another 20% : Unexpected behaviors. There are lots of examples here, that take from a few to several hours to solve: things that should behave as expected but don't, and programmers have to ask on Stack Overflow to 'keep their sanity'. This is the know-how that adds experience and increases the seniority of a developer. Examples: my past blog post mentioned how adding asynchronously images to an array mixed up identifiers, or how adding to an array asynchronously 100 elements sometimes results in arrays with a less number of elements.
Thus, to be 100% confident that I deliver a complete app by a deadline, my estimate is around 150 % of the features-only estimate.
There are a few online courses on software project management, here is a good one I took on Coursera to explore more.
Posted on April 14, 2017