With the benefit of spending years at the trenches, watching decisions and their eventual impact, subconsciously I’ve formed my opinion on what I would do if I were to start building a new product.
Using the New And Shiny
That is for me tells me that the decision maker belongs to one of the cargo-cult. I’ve been through this stage. Why not the New And Shiny? Since it is new, few would have used it. Fewer using it means the eco-system of libraries is not as mature, and you are less likely to find solutions to your problems on StackOverflow. It means the hiring pool is smaller, with people coming in to learn rather than being productive at the start. It means nobody knows where the New And Shiny’s warts are, so unfortunately you will be the one who will find those warts in production. woken up by a phone call at 3am on a Sunday morning, realising the server has crashed, and nobody knows why. Warts are found through the hard way, not discovered through simple programs written on blog posts. All these small things slows you down, a literal death by a thousand cuts to a fledgling company.
Your job as a decision maker is to deliver the product, working, on time and on budget. It is not the time to be dabbling on new technologies to add to your resume, especially when there is limited time. If you haven’t written production code using it for more than a year, you don’t know it. Use something proven, use something you know. Your customers don’t care what powers it, and your customers are the ones you should be caring about, not impressing other programmers at meetups. Most New and Shiny are another way of achieving the same thing. A new Javascript framework is just another take on how to manipulate HTML. Maybe it is faster, or more elegant, to your customers it is the same - HTML. I’m guilty of this, and I recognise it especially in younger programmers. Control yourself and do the right thing - pick the boring, stable and working technologies that you worked with before.
Throwing away working legacy code
I’ve been guilty of throwing away perfectly working code, on several occasions, using excuses that it is poorly written, performing badly, or any jargony reason to pull one over business people. It is one of those tempting decisions to make when you are given a brownfield project. It is more exciting to start in a New And Shiny technology than to work on the old problem.
For the programmer, there are many reasons to do that. First, you get a chance to learn a New And Shiny technology, add it to your resume, and to demonstrate you have the brains to pick up the New And Shiny technology which is so difficult to learn, which proves that you are one of the elite. Second, you don’t have to wade through the humongous code base, littered with undocumented special cases, and did I say no tests? The alternative is to keep the codebase, which means reading a lot of code. Reading code is boring, painful, and much harder than writing your own, preventing the conception of what could haven been an elegant architecture from you. Third, it is much more impressive to be the person who wrote X, rather than to be the person who maintained X.
There is every reason for the programmer to want to write new stuff. Not for the poor business guy. The customers are expecting this list of old bugs to be fixed and these long-asked-for features to be built next month. Sadly, those aren’t coming. The programmer is throwing away working code and writing new ones which does HALF of what the working code did. That won’t be ready anytime soon. Woe on the business guy who has to placate the impatient customer. It is times like this that the customer feels they are not loved, and there should be better solutions out there, which they promptly switches upon finding something better. Business guys, don’t fall for this, the programmers are fooling you.
Control yourself(myself included), do not throw away working code - do the right thing which is to refactor the code, add tests and documentation.
Processes are like habits
An idea that I picked up from the tech echo-chambers is that processes are evil. They belong to the big bureaucracies, who can’t innovate. Only when I witnessed how the lack of processes harmed a growing company, that I realised these blog posts are written by people who’d never scaled a company before. I have to remind myself to be careful of what I read. Processes are like habits, good habits that helps the company stay aligned. They exists because they work at scale. They help the company stay on track as they add more employees, and keep chaos sane as more customers come. Things like proper documentation, proper commit messages, a process to release, regular progress updates, helps the company to stay aligned. Again, when to introduce processes depends. I’d lean towards introducing them early to cultivate the habits early. But not too much that it feels strangling. People should not be afraid to question processes. We have a tendency to accept processes as sacred rules - they are not. They are decided in the earlier days when the company was facing problems A, but now it can be a different set of problems, and those processes don’t work in the same context. Obviously you have to change them. Use processes to help your team stay aligned, not to hinder.
Embrace technical debt
We are taught from young that debts in any form are to be abhorred. Debts are for irresponsible people, people who can’t manage their finances, like gamblers, spendthrifts. We associate technical debt in the same way, thinking we should avoid them like plague. Contrary to that thinking, at the early stages, it is alright to tolerate technical debt.
At the early stage of a company, the biggest problem is product-market fit. In other words, is the thing you’re building solving a real world problem? Iterations should be fast. You should not be agonising over how scalable the code is, or whether code coverage is at 100%. Those things don’t matter if nobody wants the thing you’re building. I’ve seen this time and again. The founders come up with an idea, fall in love with it, thinking they know best, they build it using the state of the art, so proud of what they’ve built, not realising nobody wants to pay when they start selling it. All that elegant design, all those tests, are a waste of time, in the early stage that is. Only when you have the confidence that customers want what you’re building, then it is time to invest time to do quality work.
Remote working at the start
I was a believer in remote working. Now I’m a half-believer. It doesn’t work at the early stages, when the team culture is still forming. You simply don’t form bonds remotely. It doesn’t work for inexperienced engineers where you need teach. It doesn’t work when the time zones are more than 2 hours apart. Any time difference slows decisions and hamper communication. It doesn’t work when you’re at the early stage of building the product, when the team needs to make decisions fast and communicate the common vision. Having remote team members at that stage slows things down. At what point can you consider remote working? When you feel that you’ve reached product-market fit. When you have processes that ensures quality work, and good communication. When everybody, especially the decision makers, believe in remote work.
These are my opinions. Experiences forms opinions. Nobody will experience the same set of problems - they are unique to you. Advice usually comes in the form of this is what I did when I had this problem, I made this mistake, and this is what I would do if I can do it again. What works in my context, may not work in your context. Always take advice with a pinch of healthy skepticism. But when you have encountered a similar context, and knowing that others have made this mistake, it’d be foolish to repeat it.