Code Makes Money While You Sleep

A Business post?! Yes, I still work for a living. With classes out of session for holiday, and thus a shifted focus to what is happening at work, I have some thoughts. There is a fundamental difference (in my mind at least) between a software house and a consulting house. This difference manifests itself in the house’s culture and view of the wider world. I write this with a critical voice towards the place I work (and yes I have already shared these thoughts with them).

Executing is one thing. What you choose to execute is something else entirely. When projects go long and over cost you have to ask why. Are you thinking like a software house, or a consulting house? Are you listening directly to one client and their immediate need and schedule? Or are you surveying the wider field and wider needs?

This principle of a software house comes down to a singular thought. A good line of code needs no energy or thought. The more users you can get to use a good line of code means you make money without spending any energy. Software makes money while you sleep; it is the equation of how to turn code into money.

It takes longer to write a good line of code than a shitty line of code. It is good informed code that covers a real need with many different user needs. Developers get angry if you try and ship their prototypes. The prototype might “work”, but there is not a single good informed line of code in there. In the long run you pay much more per line of bad code than for good code. With good code you pay to fix the problems before they get put into code. And it is always cheaper to fix problems on paper. The first rule of business is you get what you pay for. If the business decision calls for a shitty line of code rather than a good line of code, you’re going to pay for it. Not today. Maybe not a week after it ships. But you will pay.

The toughest part of the equation is to get all the information you need to write a line of good code. There is a world of difference between the real need and perceived need. Too often people buy into the client’s perceived need without finding the real need. Toyota became the top car company because it asked Why? five times. “Why are we doing this project?” “Because our client wants it.” “Why do they want it?” (At this point the PM will give you a snarky look.) “They need this piece of data to make a business decision.” “What is the business decision?” “I do not know.” “What will sway their decision?” “I do not know.” Why decisions are made is often never recorded. (As an aside I love Rand’s analogous Malcolm Events for making this point) So many times I have been over and over a piece of code or spec item wondering, Why? Every line of code becomes a precedent for making a good or bad decision.

If you can find answer to the final “Why?” you can spot trends and similarities between projects. And then you can focus on writing less code, good code, informed code, that solves the real Why. The real Why that is going to make you money while you are sleeping.

This “Why?” question is hard to get at. Years ago another developer (you know who you are) and I were responsible for the rewrite of the largest part of a product. I sat in a meeting with one of the project managers, and a founder who had domain expertise. He was telling me how the user interface should work. I kept asking “Why?”. He got very upset and said I could leave now. I told him I needed to understand who the user is, what they know, and what they are thinking about if I am going to do this project. He thought that communication was the means of organization. He wanted to communicate to me precisely how something ought to work for him, rather than discover how it ought to work based on the user. When it came down to it he knew all the answers to “Why?”. (Aside: I was later fired for being combative).

On the surface it is really hard to tell the difference between a good line of code and a bad line of code. It becomes easier when you’re looking at large chunks of good or bad code. But you only know it is bad because you keep constantly getting sent in to fix it. Bad code is uninformed code. It knows nothing about the real need. Good code knows what the need is. It is informed code. And writing informed code is what needs to happen if you want to function as a software house. It is always easier to fix anything before it gets put into code. Good code is going to cost less in the long run. The business folks making the decisions in a software house work to make sure that good code is written. Good code can only be written with plenty of time, and plenty of information. You cannot “rush” good code. Good code makes you money while you sleep. Bad code makes your pager go off while you sleep.