The Open Sky Golden Rules Of Software Development

Open Sky's guiding software development principle is that simplicity & maintainability should override everything else when building custom software projects. More specifically, we seek to affirmatively answer the following question in all our work:

Can you bring-in outside developers to understand and work productively on your code base without having to GROK an encyclopedia of frameworks, technologies, and cascading design consequences within one giant brain?

If the answer is yes, you've done well. To that end, the following are ten Open Sky Golden Rules of Software Development that achieve the above goal.

1. You must write your code several times

If you think you'll get it correct the first time you are dead wrong. Don't even try. Write it once - and do it VERY fast. The sooner you write it once, the sooner you can rewrite it to get it correct the second, third, or even fourth try. Time spent on up-front design before determining all the moving parts is time wasted.

2. Don't solve non-existent problems

Far too frequently developers play gotcha with themselves. If I do this now, then later it could come back to bite me, so I'll plan for it by writing a bunch of code now, in order to prevent a potential problem that might happen in the distant future. And so on. Sadly, this is all unnecessary and wasted time. Per the first golden rule, you're going to write and rewrite a piece of code several times to get it right. So wait till you actually have a problem to solve! Fight the instinct to look too far down the road.

3. Code from the front-end (UI/UX) to the back-end and never the vice versa

When building a new feature, function or program from scratch always begin with the end user interface and experience. Mock-up and iterate with that UI/UX first which allows the back-end and database to reveal itself to you. Time spent up-front in preparing the back-end business logic and database is universally wasted time.

4. The Internet is fast, reliable & everywhere

So please use it! First, don't write complex client-side code when trips to the server are cheap and easy. And second, please stop engaging in arguments about "what if the network is down" or "what if I'm on an airplane" or "what if I'm in a remote part of Timbuktu?" ... guess what, the Internet is everywhere now! If the Internet is truly down, it's hard on everything (not just your app). So please stop the madness of worrying about Internet connectivity.

5. Don't fear customization

Sometimes you must re-invent the wheel. Why? Because the wheel you build is better than the one some framework/tool gave you. You should not be afraid to re-implement things that seem obvious if you need them to work in highly custom ways.

6. Use (and over-use) your database

It is the cheapest, fastest, most reliable memory store you'll ever encounter. It decides when to spend time writing to disk (not you, so don't sweat it's I/O). Don't write custom in-memory this or that for convenience or performance sake unless you absolutely, positively have no choice. And please put everything and anything useful into your database. Need absolute dates as time since the epoch? All good. But PLEASE put a human readable date field somewhere (for by-hand queries). Don't make yourself do sql mathematics and acrobatics just to be economical, canonical, orthogonal, or any such dogma.

7. Optimization is overrated

Don't obsess over how efficient your code is unless you've gotten very sloppy (like a bad object, routine, or join that is obviously wasteful). You will always find a better way (per the first rule) since you're going to rewrite your code anyway, so optimize it then - not now!

8. Test last

In contrast to to the "test first" or "test everything" that guides many development teams. Test at the end, and test from the UI as if a real world user were on the system. That's where the rubber hits the road. Testing too early in a project is both a productivity and morale crusher. Everybody hates testing, and for good reason. So tread cautiously.

9. Avoid complexity

If your code relies on a some really nifty tricks, some crazy reflection, a custom LIFO/FIFO, or mind-numbing esoteric algorithms you have failed because every developer who follows you will need to rewrite ALL of it. Keep things as stupid simple as humanly possible. A famous software adage comes to mind, namely: Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

10. Introduce third-party libraries with extreme caution

DO NOT introduce yet another library just to make use of a couple of functions. Better to simply write the functions custom. Grab-bags of libraries lead to complexity and brain ache - it's the kitchen sink approach to software development and violates all the above rules and our guiding principle.