How To Develop Unmaintainable Software 211
jones_supa writes "Greg Jorgensen specializes in debugging, fixing, maintaining, and extending legacy software systems. His typical client has a web site or internal application that works, more or less, but the original developer isn't available. Greg lists some things you can do in your own software projects to keep him in business. In summary, the list goes as follows: Customize your development environment a lot, don't make it easy for the next programmer to start working on the code. Create an elaborate build and deployment environment and remember to leave out the documentation. Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features, and mix test data with real data in your database. Don't bother with a well-understood framework, write everything from scratch instead. Add dependencies to specific versions of libraries and resources, but don't protect or document those dependencies. For the icing of the cake, use the coolest mix of cutting-edge programming languages."
Frameworks (Score:3, Interesting)
Is this saying only use widely-available frameworks (to do it "right"), or don't write your own frameworks from scratch? I have time-tested C.R.U.D. frameworks I often use for web projects that I've improved and tuned over the years. They are reasonably well-commented.
Re:Old news (Score:5, Interesting)
lol, 25 years ago we had ONE programmer able to maintain our software as he had done much of the customization of an out of the box accounting system. Bloody thing was so complex to start with noone wanted to touch it before we fixed it up, much less afterwards. Upto 10 Megabytes worth of code but no more than 32K loadable in memory. Must have been 100's of small chunks of code all calling each other in and out of memory every other keystroke.
I managed to customize some reports but that was only part i ever dared to touch.
The real kicker...written in a version of BASIC.
Actually a pretty impressive system and worked well for 15 years. Always wondered how they managed to write such a monstrosity. Kept picturing a blimp hanger with a flowchart wrapped around the walls.
He Didn't Delve Into Specifics (Score:5, Interesting)
A couple times I've run across some jackhole who is in love with dynamic shit and who wants to check java object code into an SQL database and dynamically load it into a program. Nothing quite spells fun like wondering where the hell the code is branching to, and spending two days figuring out it's to an object in a database the code to which has been lost 4 years earlier.
For a long time there in the '90's and a bit later, version control wasn't a normal thing. If you had to get management approval to set one up, that usually would start up the sinking feeling about that job sooner rather than later. Nothing quite like having to justify the addition of something they should have never written a line of code without in the first place. Nevermind trying to get overhead for writing unit tests. Assuming unit tests are even possible. For most of the projects I've run across, the coupling is so tight there's no way to get in and test discrete functionality of anything.
For the guys not using version control, "Lose the source code" is a good one. You don't even have to be malicious about it (Though malice helps.) Just build the thing on your personal dev box, deploy the executables to production and never mention it when you leave. Bonus points if they walk you out during a layoff.
"Don't set up a build system" is another good one. Gotta love those projects where you have to run a top-level build three times before it produces an executable!