Last week we spoke all about how to make the right technology choices within projects, so today, still wearing a technical hat, let’s discuss how we approach project delivery, our engineering process.
If you were to imagine a Venn diagram of the whole process, there’s quite a big overlap in the middle where engineering meets project management. The difference is that engineering mainly focuses on actually getting stuff done, and the project management process focuses more on the reporting and checking up on what’s going on.
It’s not a linear process
Essentially, engineering is that set of activities we do to design, build, test, deploy and eventually maintain and support a piece of software. However, a lot of the time these activities or steps aren’t as well defined as other processes like project management. Their definition is left quite open.
That’s because software engineering isn’t like constructing a building; it isn’t a linear sequential process from groundworks to painting and decorating. In software you can always go back and change the foundations. However, the more you add to your software, the more chaotic and interconnected it can become, which makes it harder to reason about, and means that changes or problems can cascade through large swathes of the system having a much larger impact than you anticipated.
Good engineering is an iterative process. It’s about making a low-fidelity version of something and working up. Having this mindset is key to designing a process that works.
A lot of the non-tech founders come to us with this little Excel spreadsheet with 200 rows of things they want doing. They just want to start ticking them off from the top down thinking once it’s done, they can move on.
But it’s never really done. You’ve got updates to your operating systems, your changes in dependencies, bug reports. When issues come up, you need to respond and deal with them. It’s not a process of “build it once and forget about it”.
Try not to plan too far ahead
So, having that agile mindset is important. Nobody can predict how long these things are going to take, or actually what’s involved in the process. There are always going to be things that turn up that you’re not anticipating, which is why I always prefer the more incremental and iterative approach to engineering.
For example, at the highest level, we want to be able to bash through and get as much of our build done as possible, without worrying about tiny little details and making everything perfect. We just want to see that it works, and we are de-risking the project as much as possible. The main thing initially is to get started and have that flexibility and agility to adapt. Try not to plan too far ahead.
On the first run, things will never be perfect so don’t spend too long trying to make them that way. If you do, it becomes very easy for the project to keep getting drawn out. You’ll never quite be ready to say “I’m done, let’s put this down now”.
But if you go into the process with a different mindset, knowing you are going to revisit and polish it up soon, you don’t get those hangups. You can move on quickly, and even though you may revisit something a few times it makes the whole process more efficient.
Don’t be scared of the hard bits – release little and often
However, knowing you will come back to it doesn’t mean you should postpone the most difficult bits for later. Do the tough stuff first to de-risk and learn from them. Make sure those bits basically work and then put the additional details around them when you come back around.
Don’t be scared of the hard bits. Some people build up this fear about releasing something. Because they are scared of failure, they postpone the release to do extra tests, or to bundle many releases together so there are fewer opportunities for failure. But now the release is more pressured and it is much larger and hence even scarier.
Rather than running in fear of the thing that hurts, you need to practise it. Practise makes perfect, right? If releasing is hard, then release often. It means that you get good at releasing, you get good at resolving issues, and you get known for being a fast, responsive startup who listens to its customers. Your first release can’t break anything, so it should be the easiest, but it is often the scariest for founders. It is the first time they are exposing themselves to the public and they want everything to be just right. Again, delaying just makes things worse. In reality you probably have nothing to be scared of, you have no customers to lose and all the customers and insights to gain.
Automation – the developer’s best friend
Nowadays, in the modern era, the biggest and the best thing you can do is use automation in your engineering process. At tsf.tech it’s something that we have embraced from the very start. It enables us to be able to release something within a week, and then again every week.
Also, if you have the right setup you can practice that release every single day! Constantly building experience and confidence to support future releases.
Check out our recent blog on cloud technology, or for a deeper discussion tune into episode 7 and 8 of our podcast “From the Factory Floor”. Automation radically changes the way that you can approach work. Manual processes are not only slow and resource intensive, they are repetitive and error prone, but worse still they cause the developer to behave in certain negative ways to avoid the pain and the personal expense. Automation liberates them from fears and the mundane allowing them to focus on solving problems and writing code. It enables them to experiment without worrying about unintended consequences which results in more innovative solutions. A fast automated test suite enables a developer to test frequently and repeatedly which changes their approach to quickly try one or more solutions and efficiently move on.
It’s worth the investment
Now, there is an argument against investment in automation too. You can end up putting an awful lot of effort into setting it up and the upfront cost may be high. However, the alternative is far more painful in my opinion. In the startup world, we have to focus on low budgets and quick turnaround, and it can be easy to decide to skimp on testing. But what is the cost of having your development team spending time writing tests rather than building new features?
It can certainly be tricky to find the right balance, but I would still recommend automation from the start. It’s like financial investing; some effort now will pay you huge dividends in the future. My advice to startups is to start automating from the top down. If you write lots of low-level unit tests initially, they won’t properly check that the whole system works. Additionally, you will have to rewrite them every time you change the parts.
But if you write tests, focusing on the user’s perspective, things shouldn’t change that much. You can change your entire back-end system, and it doesn’t matter. Your API still returns the same results.
Keep it simple!
With all of this in mind, the most important thing to remember when it comes to the engineering process is to keep things as simple as possible.
It’s true, for larger projects in companies with teams of 50 plus developers, or overseas teams that the process does need to be a bit more rigorous. But they are different beasts altogether. In a startup, with a much smaller group, dealing with things directly is far more efficient.
Since we started tsf.tech we have really tried to streamline the process and found that you don’t even need half the stuff that other places implement. A lot of it can get chopped down. In our JIRA setup we have one issue type and 3 statuses, which are; to do, in progress and done. You really don’t need anything more.
It reminds me of this “hilarious” joke: What’s the difference between a bug and an improvement?
Answer: A pointless argument. (cue the drums…)
But it’s true. In a startup, there is no point in having these different complex definitions of what things are – they are all just things that need prioritising and doing.
Wrapping it up
Keeping things simple. Do the hard things early and often. Development is a non linear journey so don’t follow a linear process. Plan to iterate and revisit everything. And invest early in automation to liberate your team, change your approach, reap a much better ROI.
I hope you have found this useful, if you have any questions or would like to hear more about the engineering process check out episode 9 of our podcast, “From the Factory Floor” where myself, Aleska and James go into more detail. Alternatively feel free to email me at ericc@thestartupfactory.tech
More next week!
