To actually ship software, add constraints

When you build your software, you don’t have the usual constraints which you have at work: you don’t have a deadline, you don’t have specs, you don’t have customers asking for features, no agile plan with stories, sprints, points and tasks. You’re your own boss. You can do whatever you want. For example: you can write your project in a niche programming language maybe 500 people in the world use. And this is why programming is great.

Problem

The lack of constraints is disastrous for us. As people we want more money, time or fame. As software engineers we want faster processor, more memory, more bandwidth. But constraints are what makes us going. They are here to be creative.

Let me give you a mental exercise here. To benefit from it, done peak at further paragraphs. Just take your eyes of the screen for a second and think. Here it is:

If I gave you right here and right now infinite amount of money, infinite amount of time, ability to fly, read a human mind and teleport yourself in a blink of an eye, what would you do RIGHT NOW.

Now the second exercise is this:

If I gave you $50 dollars, 50 minutes, and a nice shirt and pants, what would you do RIGHT NOW?

Unless you’re extraordinary (in which case you can stop reading this – better go save the world right now), I bet it took you less time to come up with an answer to the second question.

Delivery of software is the same. With constrains it works much better that without it. My take is this: impose constrains on yourself.

Root causes

First problem is that software engineers are optimists. You like what you do, you believe you can do it, and you start hacking things. When you approach the problem however, you start to have doubts. It’s actually harder the way you though. It’s actually massive. You find yourself reading three times more than you wanted, and it looks overwhelming. What you could do with your current knowledge is nothing compared to what was in your head. You wanted a castle with an ocean view, and all you can do for now is a wooden shack.

Second problem is that perfection and software want to go in pair. However each date of the two doesn’t go too well. It’s as if one wanted every painting of an artist to be a immediate hit. A masterpiece. That rarely happens, and you get frustrated. You thing isn’t as nicely looking as the source code you find around the Internet, so you stick it on the bottom shelf of a desk and you forget about it.

Third problem is the freedom of making software. It can be disastrous, in fact. When you attempt to “be on top” – follow the trends in fear of not being able to catch up. This industry is so dynamic I can’t stop following trends. My take on this is that it’s all crap.

Solutions

As of now rule. Write the software however you can as of now. Learn as you go, and throw new constructs, methods and functions as you go, but don’t reinvent things in the middle. This works best if you have a product in mind, and you do whatever is required to build this product. But even for just pure software exercises I find it better to write crappy software version A, and then less crappy software version B and take retrospective on the two and compare them. And yes: this won’t be the greatest software on Earth. It won’t score awards. But it’ll be working fine and will be consistent, and what’s the most important: once you figure out your mind framework and your toolbox as of now, you’ll be able to make progress quicker.

Stick to what you know. To give you a practical tip on how to achieve this, imagine you read a book. You’ve covered ‘if’, ‘else’, ‘switch’, ‘for’ and some basic structures. Design your program like this. And finish. By the time you reach classes and inheritance, restrain from throwing them in and removing the old code. Wrap up your program as it is, as long as it works. And bum – you’re done. You’ve completed something from A to Z, and it works. When version with classes arrives, you can compare the two and see progress you’ve made.

Stick to style. When asked, one of my mentors gave me the advise: write a lot of code. When you start a project, pick its technology. And style. And then stick to both of those. And wrap the project up without modifying them. You may be unhappy with your choice, but it’s much better to finish a piece of imperfect software, then not to finish at all.

Stick to frameworks/library choices. If after spending thirty hours you realized that you’ve made a bad choice with a framework, library or a framework: stick with it. Unless it’s absolutely impossible to progress with your choice, stay with your initial choice. This is how most real-world assignments will look like anyway: you’ll get to work on a huge body of code written in technologies that are old or “seasoned” and you’ll have to add new code there.

Time

The most important constraint is the time. Pick a timeframe for your project. Partition it into hours of minutes. If you can spend at most 30 minutes every day on working on it, set your expectations straight: it’ll be hard to ship an industry-grade code with 30 minutes a day, unless you stick to it for an extended period of time. Time constraint is good, since again: without a constraint, switching programming languages, programming style or frameworks and libraries will cost you nothing, while in reality it’s expensive. It’s like re-doing a brick house walls when the foundations are already in place.

Pressure

Some of my best products and the worst code I wrote under time pressure. When the thing you’re building must exist by next Thursday and you know the damn thing isn’t yet building, not to mention of a notion of “working”, you get pushed to the wall. Your adrenaline starts to work, and your brain gets into a higher gear. At least that’s how I experience it. In situations like this, I don’t deliver great software. By no means it could be shown in a class as an example of the “industry practice”. But it works and gets me further.

Impose the pressure on yourself and setup a deadlines. And meet them. In case of getting close to a deadline, start cutting a scope of the project. And never push the deadline. And keep the log. At the end of the year, you can see how many of your ideas were actually completed on time, and how many you’ve dropped.

Shipping is a success. Failing to meet a deadline is a failure. And remember that any bad but working code is better than pristine clear code that doesn’t nothing, or isn’t complete. In my case all “pressure code” could be rebuilt and refactored later.

Give it a try

Before claiming rules above make no sense, give it a try. Next time you want to backtrack on your choice of “fundamentals” of your project, think of what we just covered and try to follow it. And then let me know how it went and what the end result was