— Software Engineering, Work, Productivity — 4 min read
In this post we are going to talk on the modern software development process and how to optimise it for speed. After all, an ability to quickly come up with ready-to-market MVP or even a full product is extremely crucial for either a startup or a large corporation. There are multiple things required to achieve it, such as a solid go-to-market strategy, some trusted zero-day customers, etc. However we are going to focus on the execution here. Assuming you've got a good idea, how would you structure you engineering process to iterate quickly?
This is going to be the first collection of engineering productivity hacks. Further, I am planning to go deeper in some of those. So stay tuned :)
Really(well except if you are)... do not go crazy about fancy tech stack. From my experience, there are really limited amount of business cases when you need some crazy infrastructure to back it all up. Extreme examples would be: Social-graph based businesses, video streaming platforms, public storage systems, some online games, etc. Check out Changelog' episode on this one.
So, keep things simple and rather spend your time on development of a proper structure for your application, where certain components can be easily replaced with more powerful solutions later(if you will need it). Let's admit, in most of the situations you do not need a full self-managed Kubernetes cluster to run your app. Also you do not need to split your application up in 100s of microservices and then try to figure out which service mesh should be used to keep this thing under control. If you have an app with say 10K users, it just does not worth it as the only thing it brings is a mental overhead to understand system architecture. Check out a desperate post from Kelsey Hightower on why monoliths could be the next big thing :)
Sounds simple, but still a lot of people get it wrong. You do automation not only to do some stuff faster, but also to have a deterministic environment and avoiding human factor in your system. Nowadays you do not really need to develop automation to deploy your system as most of the cloud platforms allow you to do it with a single command. So, there is no need to automate single command, right? What you need instead is to figure out a healthy level of testing you need to perform to make sure that your customers get what they expect. Also, you should really spend some work on gluing all your internal systems together to make sure your deployments are visible and results/system changes are clear to everybody. Like ideally you may want to push your code, and expect that after a round of automated testing and required infrastructure changes your app stakeholders will receive a clear changelog, explaining what exactly happened and at which time.
Really... Tooling is everything nowadays when we are talking about efficiency. I strongly believe that automation is a vital part of your product and must be considered as the first-class citizen and any stage of the product lifecycle. Tooling is also extremely important for things like product support activities and debugging. As it turns out, for any relatively complex application you will have to spend some time on toolchain development to make your life easier.
Be very careful with your assumptions. Try to measure where it is possible. Assumptions are super dangerous when running at scale. The things you might have considered to be an edge case might still be an edge case but as your traffic goes up, an absolute numbers of such edge cases will grow up too. The right way to handle such things would be to consider a proper analytics/monitoring/reporting systems from the very first days of you application. This might be a tough one as it is sometimes hard to justify working on analytics system for the new app which does not exist yet, but believe me, you with thank yourself for having a historical data from the day 0. It is much easier to make further decisions when you can look in history and see how your system performed in the past.
In a modern software development world it is super hard to keep an eye on all of the things happening around. So, you better help your colleagues to navigate through this world. And they will likely help you too. From the company culture perspective, things like TechTalks work nicely. You just gather together and listen your peer making a small presentation on what he/she has learned. Not only it brings people together but also enables a nice knowledge sharing framework.
If you want to move fast you must learn accepting temporary workarounds. There are a lot of engineers with beliefs that system should be perfect or do not exist at all. I strongly disagree on this one. At least this is not how our world works and this is likely not how your customers are thinking about your software. There are some exceptions of course - banking, trading, spaceships, car software, etc. But if you are not working on one of those, it is totally fine to have some non-perfect parts in your system. Whats you should develop instead is a solid system to track these workarounds and communicate their existence properly. Afterwards, it should really be a matter of engineering and product dignity to rework those parts and provide a perfect solution(note, perfect solution is still here, we just delayed it a bit)
Ideal engineering process is quite similar to a nicely written software. You've got some modules (teams) communicating with each other using standardized messages(APIs). Each module(team) is side effects free and totally independent. However, this is not how it works in reality. It could happen that some team failed to deliver or just overestimated their velocity. In such a situation, all the structure falls apart. One team is starting to wait for another one, causing subsequent delays in their development process, which might potentially delay other teams. My recommendation here would be to stop making assumptions about another team performance. If you know that a business critical API from another team is not ready yet, do not just seat and wait until its done. It is very likely there are some other tasks that can make your team move further.