These days, in which micro-controllers secretly control everything from your refrigerator to your brakes, doing almost anything requires a bit of programming. Following these rules helps.
It seems there are some simple rules of programming that aren’t taught in school, but that are vital to building solid software systems. The forces that shape the rules are universal.
These probably belong to someone else. If you like them, attribute them to the correct author. If you don’t like them, suggest one that better suits you.
#1) Never be more than three days to working code.
#2) Make it work, then make it fast.
There are more, but I have been involved in more disasters because someone (I admit shamefully, me) hasn’t followed those rules.
Rule 1: Never be more than three days to working code
Every developer hates this rule, and tries to reject it whenever I propose it. The rule means what it says. Do NOT go off on an implementation frenzy that will take you “just a few weeks”, no matter how great the expected outcome. Don’t do it.
I don’t care if the result will be great, or if the total effort is “so much less” than doing it as a series of steps. Force yourself to accept the greater effort, the additional communication required with others, the complexity of re-integrating changes, and the accountability of checking in with the rest of the project.
A few answers, any one of which is good enough to justify the practice:
1) Projects change. Over the course of a few weeks, the objects may have changed. If you are out on a developmental desert island, your best ideas may find they have no home when you return. Staying close to the project drags you along with the changes in objectives or scope.
2) Priorities change. Your brilliant changes, while not ready, may need to be put on the shelf until other work is completed. If you aren’t tracking the project with your postponed improvements, integrating them months later may be intractable.
3) The problem might be harder than you think. A week can turn into a month, and leave you chasing a vanishing dream. It is better to find out quickly that a promising method is more illusion than reality, abandon it early, and get on with something better, rather than to struggle with an unwieldy change, rapidly disappearing schedule, and a tarnishing reputation.
4) You aren’t working alone. No matter how tactically you plan your changes, others are making changes, too. If you aren’t constantly re-integrating — keeping the parts synchronized and operating together — changes that others make can render your insightful changes a failure. If the boss has to choose between a working system without your changes, or a broken one with them, which do you think will prevail?
#2) Make it work, then make it fast.
An enlightened boss (Ed Gavrin) used to say, “I can make it as fast as you want if it doesn’t need to work.”
A corollary of Ed’s principle is the down fall of many projects, including one disaster I lead as a young programmer. I could go into the full details, but this isn’t a confessional, and some of the more seasoned programmers who could have nudged me away from disaster fell under the same “pall of performance” that I did. The problem was that I lead everyone into a far more intellectually demanding implementation, in the name of making it fast enough to please the customer. All that elegance, the mathematical beauty, although elegant and appealing, made the development more difficult. What should have been one line of code could easily become twenty. What could have been solved with a well-known algorithm required developing new approaches — which we did, successfully, but at huge cost of time and people.
After the project scope had been increased from 3 people to 30, the time lengthened from 1 year to 3 — all with the approval of the government contract monitor (the customer) who wanted the efficiency — it was mercifully terminated. My company did fine. Our experience helped us win the next contract. We got paid for our work. But, what could have been a great product was buried beneath the complexity of implementing it. Even though I had been personally rewarded for my effort, I left with a feeling of failure.
When it was over, three things became clear:
- The customer’s demand for performance was based on wanting it to run on a particular computer, already obsolete, at a particular lab, and
- The performance problem was a fiction, because the processing we had through would dominate the execution time was actually relatively rare, and
- There was a better way to solve the performance limiting cases that did occur that would have added no complexity to the bulk of the code.
How does this relate to getting involved with STEM?
It means allow yourself the freedom to do something, but do it quickly without worrying too much about the end result. Don’t make the problem harder in order to make it “better”.
Look at it, use it, learn from it.
Do it again.