isn't quite ashamed enough to present

jr conlin's ink stained banana

:: Rules of Deployment

The following are JR's Rules of Deployment:

Note: The following may be sweary.

1) Server, then Client, then Marketing

Everyone's job is hard. So why the hell would you make it even harder by forcing folks to work on highly unstable things? First, build the back end server your thing is going to talk to. Get it to the point where it's stable, reliable, and predictable. It supports all the API calls properly, has reasonable security, sufficient redundancy and nobody is going to ask why the box is down.

Once the server is stable, then start building the client for real. You've got a reliable box and test cases you can use. Yes, there may be some additional tweaks to the server needed, but the core API should be fine enough to do productive work. Get it working to the point it's minimally viable (hell, feel free to roll it out as alpha to get some real usage models and proof the load support).

Once you've got a working client and sufficient knowledge, then you can start marketing and planning on your release, and not a god damn second before then. Yes, this means risk. It also means that customers/vendors/whoever won't be screwed because you're going to have to slip delivery dates because you forgot internationalization, or that we live in a base 10 world.

2) Know What You're Building

But, how will you be able to build a server, then client like that? Easy. You write up requirements. Not "User Stories" because i have yet to see anyone figure out how to build Integration tests off of "Bob wants a sandwich, so he presses a button on his phone and a sandwich arrives." You don't have to generate MILSPEC-25 compliant requirements that detail every action of every menu choice you're ever going to need, but you had better figure out the overall functions, interactions and compromise points before you even fire up your editor.

NASA doesn't send probes to Uranus by chucking cellphones "Somewhere. In that direction. i guess". The think that crap out because they DON'T have a huge budget and unlimited resources.

If you're a developer, demand to see the competitive product feature comparison chart. You're going to be building stuff that uses it, it's every bit a required resource as a man page. Yes, this means you can't be "agile". It means you know what the hell you're building and lets you recognize if you're making a mistake.

You will make mistakes. You will toss code, ideas and work out the window mercilessly. If you find you're incrementally redesigning your entire project, stop that project and design a proper one.

3) Know Your Critical Path

If you have a delivery date. Write it in large type on a very visible wall. You know what you're building, and the order it needs to be built in. You know that you'll need to do at least two weeks of systems testing, plus at least two weeks for patches, two weeks for deployment. Those are not things that can be done in parallel, so that's a month and a half of blocked time. You'll also need to build the damn thing, so figure your time, accounting for one additional month for every "cutting edge" or unfamiliar tech you're going to use. That IS being optimistic. Reality will probably demand more time because "cutting edge" means "broken and unsupported features" and unfamiliar generally means "you have no idea what it really does". These are common words you don't like hearing from your doctor or car mechanic so why should you want to hear them from your own team?

Lay out the critical path. Know what impacts what lays beyond it. Recite the critical path every morning in unison in the parking lot. Whatever it takes so that folks know that having a problem isn't what's bad, it's not communicating that there's a problem.

4) Build for One or Infinite

This gets into design and deployment bit again, but basically, you either need one of something, or you need an infinite amount of them. If you only need one, focus on that, and don't bother adding in clever crap. If you need infinite, build it as a service. (Again this is where "knowing what you're building" really helps.)

5) Make It Safe From Yourself

As a VERY smart paranoid security person once said: "Hackers have infinite time and resources. If there's a weakness, they will find it. If you, the person that wrote the code, can't figure out how to break it and do anything other than what was intended, hackers will have that much harder a time."

i constantly look for exploits against my own code. i sandbox anything the user has access to whenever possible. i always ensure that the owner of the server has the least amount of access possible.

6) Build Simple.

More moving parts == more things that can break.

If you're bringing in hundreds of libraries and support frameworks, you had damn well better need every line of code from them. Libraries are feature and code sinks. Very seldom are they pruned, and honest profiling can show how bad a lot of those "easy-*" or "simple-*" things really are. Be brutal about how little you need. If you're using a 10 line function out of a 2,000 line library, yank those 10 lines (and credit in the comments). If nothing else, this will let you see how crapped up those 10 lines are and if you can't do it simpler yourself.

i mean, it'll all show up in the profiler anyway.

You're running a profiler, right?

7) Document

Code is self-documenting if you never want someone else to deal with it. You don't need API guides if you never plan on someone else reusing your code. There are a lot of corners you can cut if the code is disposable.

If, however, you want to do other things with your life than support a 6 year old XML parsing library, write some damn documentation. If you're writing in some edge language, give people a reason to want to learn it so that they can help pitch in. You could write the most amazing thing ever in heavily obfuscated Perl that generates Pentium byte code and people would treat it like toxic waste unless you explained why the hell you needed to do that.

Granted, if you did that for "fun" you're an idiot and deserve to have the project rewritten on you, but that's beside the point.

Your documenting for your QA, Ops, NOC, and Customer Support groups. Even if those folks are you 2 years from now when things break due to expired dependencies.

Before you can tell someone to RTFM, you have to WTFM.

There are other rules, and if need be, i'll define those as well.
These are the core.

You're welcome.

Blogs of note
personal Christopher Conlin USMC memoirs of hydrogen guy rhapsodic.org Henriette's Herbal Blog
geek ultramookie

Powered by WordPress
Hosted on Dreamhost.