After years of developing software and being part of the tech industry there is one clash that is consistent no matter who the provider or the client is – and that is the rivalry between on time delivery and delivering proper software. In rare occasions you can have both, but predominantly one ends up split between the two due to multiple factors.
Over the past year, our portfolio company, WAPP, have been involved in very large projects as well as very small projects and I have been reflecting on why delivering good software does not play well with time estimates and planning in general. During my career I have seen all types of projects and worked with different types of teams and the one thing every project had in common, despite the project size or client, is that if we “build it properly”, we run past projected deadlines.
Whenever we do deliver projects on time, it is either due to the scope that reduced or we had to cut corners in order to meet impatient clients’ unmovable deadline and end up with so much technical debt in the process that the project would need re-writing in the near future once it has been launched. This leaves me asking whether the project was actually delivered on time, or is it just a less maintainable bug-ridden version of what we set out to build in the first place.
We have delivered amazing projects on less strict deadlines, where the clients weren’t so dependant on the delivery being on a specific date. In these cases we had the opportunity and the time to really polish it off well and build software that is not just solid and sustainable but well maintainable.
The beautiful thing about these projects were the mental state of the development team. A happy developer produces much better results. It all comes down to joy. I see on a regular basis the impact that joy or the lack thereof has on the output of a team. If a team works under unrealistic pressure to meet deadlines the joy goes out the door, frustration creeps in and results in a frustrated code base.
Finding these projects are rare, which is why I chose to write this article. We need to step up and force the change by changing the expectations of our clients and make them believe that good software is produced where enough time is given.
So what makes it so difficult to deliver a software project with in a fixed time frame? The bottom line is creativity, craftsmanship and unpredictability.
Although software development is not design, there is a strong creative element to the process. Obviously there are tedious tasks that is not creative at all, but solving problems, building solutions and creating successful user interfaces takes a huge bunch of creative juices and thinking. many of the most insane programmatic issues need serious creative thinking to be solved, instead of programmatic thinking.
I am a creative director by trade and I have, on countless occasions, given valuable creative input on solving a programmatic issue with my development team. This happens more often than you can imagine.
Whenever we take on a new project we push the boundaries of possibilities and try new ways to solve problems in much more efficient and creative ways. This results in a much better end-product, but unfortunately requires more time than was initially provided for the project. Often, developers come up with new ways of doing things or finds a need to go back and change something in order to do it better or more efficient, but on a tight deadline, how do you do this?
Having the time to add creativity to our development work and time for research is what brings joy to a development team. There is nothing better for me than to walk into the dev office and see the expression on a developer’s face when they have achieved something truly remarkable. That satisfaction is priceless. In the short term, the developer benefits from these moments, but the real beneficiary of such an achievement is the client.
When we work with clients that have some technical background it makes things even worse. These guys know just enough about tech to be very dangerous when putting opinions on the table. I usually ask these clients to let us handle the technical stuff and trust us that we know better. This is what we do, and we do it well. There is nothing better than being given the creative leeway to implement our own ideas and make our own technical decision to get to the end result.
Yes there are certainly times when trial and error comes into play, especially when we push the boundaries of possibilities. We need to experiment. This does not mean we bill the client for our school fees, but it does mean that we need more time than what could have been provided in the proposal or contract.
“ How to actually learn any new programming concept… changing stuff and seeing what happens. “
I have seen over and over again, that a good design on paper does not always work as intended when developed, which means space is required to amend the process, experiment a bit and find a better solution. How much time do we need for experimentation? Difficult to predict, which is why it is never part of the contract.
A set back I experience sometimes is that creativity is not there all the time. Creativity in my opinion is the result of a process running in the back of your mind and when it comes to the fore, the creativity flows. But it has to come forward first, otherwise you are forcing it, which produces an average result.
I tend to stand back when that process is procrastinating and spend time sharpening my axe instead, before proceeding. Once my axe is sharp and my mind fresh, I take down the tree with minimal effort.
When a good developer is passionate about producing new ideas, putting off the task can lead to more creative solutions.
So given all my complaining above, I am aware that this makes it difficult for the perfectionist planners out there that plan and measure every minute of the development process. Again the purpose of this article is to shed some light on what happens behind our doors so that these guys can gain clarity, and perhaps more patience, when setting their expectations.
My development team are true craftsmen.
They are passionate guys that give it their all with absolutely no shortage of drive and commitment. They are proud of their work and it shows in the tech we build.
We have developed an internal mindset to build something in the best possible way, remarkable instead of just something that works. Building something that works is easy, building something sustainable, durable and remarkable, that is something entirely different which requires time and patience.
Investing time in writing good software pays off, which is why we have started to push back on pressures to “execute faster” as we know the more shortcuts we take now, the less life expectancy your code will have and the more problems it will cause down the road.
Predictions are wrong
Irrespective of how clearly outlined the requirements or objectives are, predicting a delivery timeline is almost 99% impossible. Software development is highly complex and are made possible by humans affected by interpersonal interactions, motivation, communication issues, emotions, and general human psychology, which put together, is difficult to quantify on a spreadsheet. This is what makes it so hard for us to accurately estimate projects.
Here are some examples to illustrate some of the nonlinearities and feedback loops of writing software:
- That time when you assumed that the API you need to communicate with, accepts account_id but it actually only accepts member_id. You had to add 4 days to your estimate to refactor the API code — which in turn had to go through a separate review process which added 2 additional days.
- A task estimated to 2 days ends up taking a week because during the review process one of your team mates pushes you (and rightly so) to refactor and improve a very ugly part of the code that was long overdue.
- That one-point task where you had to implement some new functionality that happened to require an update to a dependency, which ended up taking 4 days as the dependency update triggered a chain reaction of dependencies needing to be updated and that caused a bunch of errors in the build.
We keep playing the estimation and planning game to convince ourselves and the clients that what we set out to achieve in a proposed timeline is possible, when the truth is most unlikely, and that software projects are empirically unpredictable.
Thus, in my opinion, we’d be better off just focusing more on doing rather than planning .
Of course this will not fly with many clients, which is why I always advise clients that setting their own expected deadlines is dangerous. If their companies have survived without this tech for so many years, a few more months won’t tank the business. If a client is financially dependant on the tech to be released asap, it is in itself a recipe for guaranteed failure.
Good software takes time to build and even more time to launch successfully. So banking on the revenue before the chicken hatched is insanity.
In most software projects that our clients launch for the first time, they come back very soon with changes and new features required, because the market is not adapting to the tech the way they expected. This is guaranteed to happen in any business model, so budgeting for extra time and finances is critical.
I have never heard of any piece of tech that was launched bug free without any new feature requests from their audiences. People just don’t have the same expectations than you. Accept this and plan for it and you will be fine.
What to do then?
I think it comes down to bridging the gap between the world of the spreadsheet and the world of the developer in a way that allows maximum creativity, flexibility and craftsmanship to engineering, while at the same time carefully managing the commitments made to, and the expectations set by the project stakeholders.
Communication with clients is of extreme importance here, which is why we have developed our process around keeping clients informed. Until recently most of our client frustrations have come from lack of communication. We are now using a tool called ydox.net, which is a file management system where we have shared folders and files with clients that covers every aspect of the project – agreements, invoices, development schedules, progress reports. All these docs are available immediately to our clients behind their own secure login.
Our Engineering Manager is the bridge that closes the gap and acts like a buffer between estimates and reality.
Trust is a critical element in our processes. With trust, we are able to negotiate timelines honestly and in good faith. We have a track record of previous successful deliveries that gives us the social capital we need for stakeholders to trust that when we push back on a given schedule, it is for good reason and in the best interest of the project.
We surely don’t like wasting time on projects, as time is money and we don’t like wasting money, so when we do extend time it is absolutely in the best interest of the project and client.
At the end of the day we need to stand up for the technical quality of a product delivered, not to the other stakeholders. The key is in fact, we are all aligned with the same goal: Deliver good quality software to our customers in the fastest way possible — what only good developers seem to understand, is that you should avoid taking the deceivingly “fast and easy” way as it’s actually the slowest one in the long run.
In conclusion, we prefer building the best possible software in a reasonable timeframe suitable for both parties. It is in our client’s own interest to give us the space we need to build exceptional solutions to their complex problems.
Some of the tech WAPP have built lately includes:
- An enterprise procurement system for NANDO’S GLOBAL for their international restaurant rollout of over 1600 stores in over 10 countries
- YDOX – a world class secure file management and collaboration platform for businesses.
- DIGEMY – an online education platform that revolutionises the way corporates train their people around the world
- An art management system for the largest privately held art collection in the world, with over 40 000 artworks located all around the world
- A psychological personality type profiling system for a company in Singapore
- An agricultural cloud-based app that allows farmers to plot parts of their land in the app and measure earth samples and much more info about land on their farms.
- A revolutionary stock taking app that allows restaurant and bar owners to take stock of bar and kitchen products via an easy to use stock-capturing mobile app
- a restaurant ordering app that allows customers to order food from their favourite restaurants and earn loyalty point for discount
- a financial app that integrates with XERO and gives you on-the-fly financial overviews of your company or group of companies or branches…
and many many more.
WAPP specialises in developing cloud based tech that automates and digitises manual business processes in order to save time, save money and increase efficiency and productivity – ultimately increasing revenue for our clients.