Parisista

This piece is for software technology startups (or startups using technology) with 2-5 developers, who are short on money, are on a continuous bouts of brain freeze, etc etc. However, for people who are managing 100 people teams, I’m gonna write one on how not to manage technology, but that’s coming after rebirth.

In my previous stints managing pieces of technology including developers, code base, release cycles, etc. — I was always hunting for tips for better sleep management. Huh, the solution was in managing the technology effectively to get a better sleep.

Here are some of them compiled (some learned after reflecting on mistakes!)

1. Build Now. Scale later. More often than not we worry about whether this piece of code or even this atomic function will scale or not. Once I was writing a small function to convert time into the now famous “10 minutes/days/years ago” format.  I took the whole fraggin’ day on it. Back in my mind I was trying to optimize a small calendar look up which probably optimized the code by 10 ms for every HTTP request. Big deal — but totally stupid.  Essence: Build what you can build. Do not spend more than 10% extra time worrying about scalability & performance. The objective is to get the customer first within acceptable limits of latency. Also, look at your strengths — if you are a developer never worked on high performance computing but know enough chops about writing good code, then just focus on that.
2. Release frequently, but not every day! The release early, release often is a myth which leads to disaster many-a-time in increasing code complexity, release cycles, etc. A good discipline is not more than one (yeah, 1) release every week (ideal is release every 2 weeks). Let the customers breathe, the QA breathe and stop wasting the time doing regression on the code. However, apply the exception to hot-fixes, security fixes and show-stopper bugs.
3. Prevent public bugs. Another myth of release early, release often is a conception that it is okay to have a few bugs on the code. Depends on what kind of bugs. Database connect failures? or weird on the face JS errors. Acceptable public bugs are those which are not seen by more than 10% of your customer base & depends on what stage of maturity your product is in. However, bugs when monetary transactions are taking place are a strict no. Another theory is that the number of public bugs is inversely proportional to the number of users.
4. Secure your web presence. This is getting complicated as the web matures & hacking is done using scripts instead of deep knowledge of software’s workings. In my previous stints managing technology, I thought & claimed to be ahead only to be humbled later with DDOS attacks. In my theory a 10 hour of Googling followed by 10-15 hours of fixing/implementing can take care of a good percentage of publicly known security holes.
5. Code Now. Refactor later. This is a personal anti-thesis which goes against the philosophy of designing beforehand; thinking through of the architecture, etc. Why? Startup resources are extremely limited. The objective is to show/deliver products. As a developer/technology manager you want to put your best efforts in delivering code rather worrying about the best possible way to develop a piece of code. However, it is okay to postpone some design issues (not the security ones) and revisit them after hitting some milestones. You don’t use the “refactor later” mantra to avoid the issue; instead being pragmatic about it. Also the exception should be conveyed to the team, the options available, a path chosen; with the reason that this does not become a habit within the organization.
6. Never outsource, but augment staff. The worst thing a startup could ever do is let someone else develop the technology and that too in someone else’s office! If you can’t hire full-time then hire contractors. Get them to sit with you, together. Have control and visibility.
7. Production release not tested here! Developers will always make an assumption that if it works on their laptop/private environments, it will always work on the production environment. Do not ignore that — Have a discipline of testing the code after deployment.
8. Automate everything, except your customer support. You want to automate/script as much as possible. Deployments directly from SVN, automated testing using various frameworks, log monitoring & alerting, server status, linting, database sizing, load, and every mundane tasks with actions like alerts etc. going to the team. However, you do not want to do an auto-reply to an incoming mail. OK to be slow by few hours but acknowledge/respond to each one of them. Put the startup resources to test.
9. Code all night, but release after noon. Simple. You want to do a production deployment when the hangover from a night of coding is gone. You want to start before the day is ready to end. Never deploy at 5pm or 8pm or early in the morning. Best time to make a release is at least 24 hours after the developers have said “it is ready to go!”
10. Secretly review a developers code. Highly effective. This is the best way to build opinions about a developers’ coding chops and get an edge in managing them. Find bugs in their codes, show it to them but never demean them publicly. All public code review in startups is actively discouraged.

If you can do the above well, then you can definitely sleep more using the 10 foolproof tips for better sleep management 🙂