Keeping a development environment clean and tidy can be a bitch. When you are working on multiple projects across different platforms it can get messy really fast. And if you’re managing a team of people and need them all to run your app locally things can get tricky too. Recently I’ve setup a process so that a pristine development environment can be spun up for a project in glorious isolation. And the best thing is, once you have it set-up, you can spin up new environments in just one command!
Write once, deploy many times has been a goal for rather a long time
As I mentioned in my previous post, I’m traveling for the next few weeks on a sabbatical to Europe and Asia. I’m keeping a journal of my travels on my tumblog, and from time to time figure I’ll be writing longer text posts here. Because of this, I figured that I should bring an external keyboard with me and I’ve already found it to be a tremendous help. Even writing short emails is so much easier on a real keyboard. When I was researching, I quickly narrowed it down to two choicee: The Apple wireless keyboard (with the Incase origami case) and the Zagg Zaggfolio case and keyboard.
In about a week’s time I’m taking off on a sabbatical. I’m fortunate enough to have employers who have agreed to let me off the leash for a few weeks, so I’m making the most of it.
On the road again, and learning to be more like a car than a truck
I’m using the opportunity to take myself off on a journey that will take me from Berlin to Bangkok, from Paris to Paro. But this isn’t just a grand tour where I’m off to ‘find myself’ (although I will be travelling to PBH
)—I’m also using this as an experiment in tablet-only living.
The US had it’s credit rating downgraded yesterday. For many people, it seems at first a little abstract and vaguely ominous—a chance for China to get it’s own back after being harangued by the US on its undervaluation of the Yuen. Maybe the outcome will be catastrophic, maybe not so much. Only time will tell. What Standard and Poor’s have basically said is that there is more chance than before that America will fail to pay its bills on time. But what does this have to do with quality software and how it gets built? Well here’s the thing—the way the US government are managing the economy and the debt ceiling are very similar to the way many software projects go slowly south; everyone recognizes that something needs to be done, but none can agree on what the right course of action actually is.
Don't overpromise and foreclose on your project
Ever used someone else’s code; a library or sample app online? Ever got to a point where it’s been so mind-bendingly painful that you rue the day you ever found the stupid ‘library’ in the first place? If not then chances are you’re not a developer, you’re this guy, or you’re delusional. Spurred by a conversation with Mateo, my friend and former development buddy about this, I started to think a little deeper about what the problem is with code reuse. We expect a well-made production quality piece of work, and before long we realize that we are stuck with something that is sucking time away rather than letting us develop the hard stuff faster. So when should you reuse code? Here are some thoughts on when you should proceed with abandon, and when you might want to be more cautious…
We think we are getting this...
...but often end up stuck with this
A couple of weeks ago I wrote about a simple yet powerful process for software estimation. When I was done I started to look at my excel worksheet for doing this process and figured that it could be something I could share with a broader audience. Rather than just post an excel file, I decided to create a simple software estimation app and post it here. You can go check it out now, or read on to get a bit more detail into the thinking behind it.
The estimation app in action
In my last post I told you that your next project will take longer than you think. Now I’ve destroyed hope I’m going to show you how you can use this knowledge to be better at software estimation. We’re going to use a simple but very effective technique first developed by the Navy back in the ’50s when they were building the Polaris nuclear submarine. Faced with tremendous risk and uncertainty, they had to work out how to build a missile that had never been built before, to be carried on a submarine more complex than contemporary technology would allow. And by the way, they had to work out how get a missile to launch underwater and hit a target thousands of miles away when no one had built a decent guidance system before. Oh, and the Russians were breathing down their neck with the Sputnik project. The Navy managed to develop a system of estimation and risk management that was so effective, they delivered three years early. Think your project is harder to estimate than that? Think again. Get on board and read on to find out how you can use this technique for your own means…
How long would it take you to build “the free world’s most formidable weapon”?
I will tell you how long your next project will take to release. You won’t like it, but I’ll tell you. A game is launching this week and in the story of its development is the key to successful software estimation. The game is Duke Nukem Forever, and just like the title, it did pretty much take forever to launch. Five thousand, one hundred and sixty days to be precise. That’s just over 14 years. Longer than it took to build the Empire State Building, the Golden Gate Bridge and the World Trade Center combined. It took so long, people have put up sites covering how long it took. The game is by most accounts at best mediocre and at worst atrocious—in my highly opinionated view, the duration of a release is inversely proportional to product quality. But that’s not the story here. What’s important is why it happened and what it can tell you about software estimation on your own project.
Duke Nukem Forever Launched after 14 years development; what can this big chested antihero teach you about your project?
In my last post, I outlined what I think are the twelve key constraints you need to think about if you are going to build high quality software that people want to use. As I mentioned, thinking through this needn’t be a mind sapping endeavour, and for some things you may just decide it’s not important right now. Here’s the rub though; once you’ve decided something is important enough to define as a constraint on your system you’d better think about how you’re going to test it. If not, you may as well kiss the requirement goodbye as eventually people will stop paying attention to it. Here’s how I would go about testing each of those twelve constraints:
When people talk about really great quality software, they usually think in terms of it’s utility, simplicity or aesthetics. But there’s more to it than that. A really great piece of software will bleed quality through and through like a piece of Brighton Rock (or Bognor Regis). What separates high quality software from mediocrity? It’s being aware of and planning for the right constraints to put on the way you develop software. Frank Lloyd Wright did his best work in tightly constrained spaces and awkward sites, and as software engineers we need to do the same to avoid flabby work. Here’s my list of twelve constraints I’d plan for on my next project: