blog tumblog github @santosh79 resume
May 20th 2012

Fight against Software Complexity

Why does software in the industry suck so much? Having worked at couple of startups and big companies as well, I can quite honestly say that of all the projects/repos that I had worked on, there was but one that didn’t suck. The one that didn’t suck, was I’m sure in no small part due to the fact that it was written by just one person, the CTO of the company, and since it was a license-based SDK, there was a vested interest in keeping things organized. Open source software projects, when compared with industry projects, are way easier to understand and in much better shape.

Why is that? It’s my belief that there are a multitude of organizational factors, that come into play, that will connive to make your company’s project complexity shoot through the roof, if you ‘meh’ the fight against complexity. And no, I’m not going to delve too deeply micro things such as variable names, TDD, refactoring etc. Those things work great in the micro, but for being able to enfore them in the micro, you need some macro things to be in place first. It’s those macro things that I’d like to take a step back and rant about.

Fight against complexity begins from the top-down

The CTO of your software company, is probably the most important hire you can make. That person, should:

a) Know the technology stack you are going to be using, like 
    the back of their hand.
b) Have had experience managing projects and watching them 
    fall under the weight of their own complexity.

It’s really important, that when you hand off the tech responsibility for a project/product to someone, that they have complexity really high on their list of things to watch out for. This is the foundation on which your software is being built, so this person better be someone who is paranoid about complexity and will not stand for it.

Hiring process

When hiring engineers, the focus should be on one thing and one thing only — code clarity. No eff'ing puzzles, gotchas, any other crap. Give them a simple problem that requires them to model couple of objects/compose functions if it’s a functional language, and have them write up a program. Look at how readable this is. Someone who takes their craft seriously, almost always keeps things dead simple. They choose variable names that make sense. They are anal about indenting their code. All these things count a lot. Way more than, some crazy probability question that you think is going to suss out the geniuses. You don’t need geniuses – leave them be in their university labs. You need someone who can write clear, well thought out code. If they have a Github/other open source projects, take time to read through them to get a sense of their skill. Bottom line, it’s really easy to open the door to someone and have them shit all over your code-base, if you are not careful.

Team size

I’ve seen this time and again, the larger the team gets that is working on a single repo, the more crappy it becomes. And it’s an exponential curve. If you are a startup, you probably are a little under the gun by some VC hot-shots to hire more, and look big. Screw that, keep your head count small. Hire only the people you really need. If Instagram was able to get by with 7 people (not just engineers), you probably can as well. The more an engineer has a feeling of ownership over a repo/project, the more likely they are going to be to take time and do things right. I know there are some obvious cases to be made against, having just one person/few people work on a repo. Believe me, if you have been anal about your hiring process, they probably have kept things super organized in that repo, thereby making a transition to a new engineer almost trivial. The new engineer, would probably also have a really great first impression of working with a clean and well organized repo. This is crucial, since that new person would probably think twice about screwing things up when they have been given a clean well maintained repo.

Choice of language

I’m not interested in starting a flame war here — Coffeescript rocks or Ruby on Rails still rules or Python is just great or Clojure is awesome whatever.. My suggestion is simple, the higher the level of the programming language you choose when prototyping your app, the less complex it’s going to be. I personally, have a preference for Ruby for it’s clarity — but you should choose the highest level language most people on your team know. Good engineers take their tools very seriously, so the better the tools you are using the better the quality of engineers you are going to find. As you find speed becoming an issue, instrument first to confirm out if it’s the language, and then switch over to something a little lower in the stack. It’s way easier going from a higher to lower level in the programming stack.

Development speed

Finally, it’s often really tempting to give into the mad dash mode of software development. Where all you are doing, is just cranking out code and hoping it sticks. Given a choice, between adding a ton of features in one insane sprint, just to get ready for usability testing — think about cutting down some of the excess feature fat and focus on just the core feature set. It’s a helluva lot easier to add features to a simple repo, than to one that is a rat’s nest. All of the technical debt accrued in the mad dash sprint, is going to slow you down sooner than you think and start grumbles in your engineering team.


I think the complexity creep can be nipped by a) being aware that it exists and b) taking some common sense approaches to fight it.

blog comments powered by Disqus