The more I write “real” software - not just demos, but things you actually have to make work for a user you'll never meet - the more I realize that you can never write just one application. Instead, you always have to write at least four:
- There's the app itself. This is the thing that the user runs.
- There's the tests. These will generally be about the same size as the app. Yes, a 20,000 line application will usually have 20,000 lines of test code.
- There's the build. Truly an application in itself (albeit usually not quite as big as the test code) it needs to deal with all the weird third party crap, odd test scenarios, and specialized hacks.
- There's the installer. If you're very lucky, this is a zipfile. Usually, you're not lucky. If not, you're looking at a significant effort to make sure it works right - uninstall, unattended install, rollback on failure partway through, blah blah blah.
Oh, and there's the documentation, too, although I didn't list that since I haven't decided yet whether it qualifies as an application or not. Probably it does.
Each of these things is a major effort in and of itself for any nontrivial project. Each needs to be written, tested, patched, documented, and supported. This also means that the app itself represents well south of 50% of the code, and probably less than 30%.
All of this just goes to justify the practice I've used for years: when someone asks me how long something will take, I estimate it in my head, and then multiply by four before telling them a number. It has worked surprisingly well.
<a href="http://blogs.msdn.com/pandrew/archive/2004/05/25/140656.aspx">"There is only one program and it is still being written."</a>
ReplyDeleteHeh. Don has a way with words. But he's talking about interconnectedness. I'm talking about systems engineering.
ReplyDeleteThey're both good to remember, IMO.
Craig,
ReplyDeleteI know exactly what you are saying. I just thought it was funny. Very interesting, though, that you can break it into those specific areas. It is also definitely possible to break each application into certain things that each one does (or many, many applications do) / Data Access, Logging, UI, Messaging, etc. So, a lot of the time, we are writing very similar applications, at least in Enterprise stuff, but they have enough differences that we have to redo a lot of the work.
Tools should be able to help, especially with the Build/Test/Installer parts.
btw, I had been using the multiply by 2 estimating technique and found that I was always off by a facotr of 2, so I appreciate the new rule of thumb.
ReplyDeleteI stole it from Star Trek IV, where Scotty says he always multiplies his estimates by 4, so when he does it in a quarter the time, he looks like a miracle worker.
ReplyDelete:)