 |
Storagebod had an interesting post asking why software sucks and why we don’t just slow things down and wait until it’s done right. I’ve thoughts of my own not directly related to his post but of course I want to share them. Starting at the end, software is never ‘done’. It’s never completed. Hardware can be completed because hardware development is an exact science rooted in physics and the results are therefore repeatable when the science is applied correctly. Software development is not a science, it is an artistic skill in the way that writing a novel or painting a picture is an artistic skill. The difference between a hardware engineer and a software developer is the difference between Johannes Gutenberg & Ernest Hemingway. Both important to the typeset word in general but much different in specific. Keeping in mind with software never being done the best way to improve any piece of commercial software is to ship it and then iterate on it. I don’t know of a software developer who wants to rush anything out the door, if anything they’d never ship anything they didn’t think was a perfectly formed snowflake if they could help it, but following that to it’s logical conclusion we end up with a much poorer choice of products in the market and a lot of never seen code held hostage by it’s creators who are in thrall of the masterpiece syndrome. When it’s shipping, it’s a real product. A product you hope is used by people and therefore worthwhile. If it is used by people you’re motivated to carry on and make progress with it because the realities in commercial software development are if you’re not adding features you’re losing paying customers. The folks spending their money to put shoes on your kids feet, or a roof over your head, will just go spend it with someone else. I’m not quoting from Martin or inferring anything on his part but I’ve typically found there’s an aspect of wanting your cake and eating it too to these things. If you just focus on your existing code you’re told your product is ‘uncompetitive’ in relation to others. They have feature X. When are you going to have feature X? The 2013 version of Y came out an hour ago. We’re thinking of upgrading. Why don’t you support the 2013 version yet? When are you going to support it even though by asking about it I’m not saying we won’t decide later that upgrading is a waste of our time and instead we’ll sit on the previous version for so long we’ll want you to extend your support of it? While if you do continue to add features and work on product quality you’re usually still held to standards well above and beyond the development and financial capabilities of your resources. So all you can really do is do as much as you can. The defence and space exploration industry is a prime example of the slow it all down to ensure it’s right the first time development mentality. That’s why the Curiosity Rover is making it’s way across the Martian landscape with a brain running at a leisurely 200 MHz and it required 4 days to update the 27 year old system software just to enable it to drive down the landing ramp. It should be noted that the 4 days wasn’t transmission time in the vein of an intergalactic patch Tuesday download from Earth to Mars, the four days was from when they started the installer on the code when it was fully downloaded to the Rover. The people involved need to get everything correct the first time as sending someone over to give something a quick reboot just isn’t going to happen. The result of that requirement of course is that programmer productivity goes way way down. There’s a lot of programmers writing very little code but doing a hell of a lot of testing on the code they do write. That’s acceptable because it suits the needs of their operational environment but they have a specialised set of needs (Average journey 225 million Km. No breathable atmosphere. It gets wicked cold at night.) uncommon in IT. So, my prime example of the slow software movement exists today. Everything from the phone in your pocket to the TV in your living room is an order of magnitude more complex. Now imagine your most intensive production application and think of how much more complex that is. Is slowing it all down the answer? Well, if you want to continue to use systems that were state of the art ten years ago it could be your personal answer… |
