Slashdot Mirror
How To Develop Unmaintainable Software
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."
Every one of these points hits the nail square on the head.
The key to take out of this is: document document document! At minimum you should have a set of instructions to re-build your dev and build environment. "Insert the <your company> dev workstation image v4" is not allowed to be a step! Your elaborate continuous integration multi-tree setup and mountain of environment setup scripts and template directories are great until the guy who set it up takes off and you have to upgrade something. Ideally a set of instructions talking to the motivation of certain decisions, roadblocks encountered, etc.
One thing the article doesn't have is have lots of 3rd party tools and keep the license servers/license files on whatever box is most convenient for the dev working on it at the time.
Well, maybe you should try this much more venerable, thorough, and entertaining encyclopedia of unmaintainable code tips. Should make you as immovable as the CEO's firstborn.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Often it is how a project is initially managed that results in an unmaintainable system. A few simple mistakes can send a project straight to hell from the very beginning. A simple one would be to allow the senior management to firehose new features at the project far faster than the developers can build them. Another would be to allow the wrong people to pick the core components. That is how bad databases/languages/operating systems can be chosen. Then you get the next layer of wrong when people simply code and architect badly.
An example from my past was a company that I interviewed with (and was offered a job at) that was using Lotus notes to build a huge educational system. They had a PhD as the head of development and they were keeping the details secret until they made their offer. When they told me Lotus Notes I just laughed; I thought they were joking. I told them that building their system out of Lotus Notes was like building a car out of sand and white glue. At first you will quickly have the broad outline of a car but that as you start to work on the hard bits that you will never finish; Ever! A couple of years later the company imploded with no real product just a bunch of sales demos.
Well, maybe you should try this much more venerable, thorough, and entertaining encyclopedia of unmaintainable code tips. Should make you as immovable as the CEO's firstborn.
He has an unfair advantage in the area of unmaintainable code since he is writing about C/C++.
Second class citizen of the New Gilded Age