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.
In all fairness, outsourcing it to Canada made sense. We're cheaper, we have health care already, and speak English with an approximate degree of usefulness.*
So, on behalf of our country, I apologize for any inconveniences you have suffered from the sheer shittiness of the ACA software. As a measure of our sincerity, you may pick up one(1) bottle of maple syrup from our strategic reserve.
*offre non valable au Québec
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
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.
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!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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
Well understood frameworks tend not to be highly optimized. If you are dealing with something where performance is absolutely critical, writing it 'from scratch' will probably get you better performance than taking one of those 'well-understood frameworks' out for a drive.
Sure, of course, why not. It's not like your time is valuable or anything. And naturally, you will make this decision before coding starts, and thus before any measurements that the framework was actually slow, or for that matter that it was part of the perf bottleneck of the system. Nothing says "job security code" like elaborate cryptic algorithms to improve asymptotic performance of some in-memory task on a system where CPU never got above 5% in the first place.
Let's not forget how bug free a framework used widely by thousands will be - there's no job security there at all if there's no bugfixing! But if we write our own, then there will surely be some horrific bug in the field that we can work until 4AM to fix, and management will call us heroes!
The main thing, of course, when writing your own replacement for some common library that some new hire would already know is to avoid any documentation, and ideally abandon the effort halfway through, because the project ran out of time, only ever use 10% of what you wrote, and never document which 10% - heavens no!
To make doubly sure that no new hire could ever support this code, remember to follow this key element of Abject-Oriented Programming:
Documentation
It's said that code should be written for people to read, so it follows that documentation is written for no one to read. Documentation should be written for every new module and then maintained as changes are put into production, or at least the next time thereâ(TM)s a lull in the workload.
A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code.
Cluttering up the source code with lots of comments explaining what the code is trying to do is distracting and slows down the compiler. That's why abject shops that follow "best practices" keep documentation in a document management system where programmers can't accidentally delete it.
Sage advice, I'd say.
Bottom line here is that this 'list' is just the logical conclusion of a career of mediocrity spent shifting blame around instead of working the problem. Real programmers can use anything
Perhaps you missed the part that the author of TFA makes his living answering panicked calls to bugfix production legacy code, presumably because some "real programmer" did in fact "use anything", and this advice is based on long experience of what makes code unmaintainable. My own experience/advice lines up with his rather well in this area, I'd say.
Socialism: a lie told by totalitarians and believed by fools.
You fool! That code is critical, it's the speedup loop. For the v2.0 release you delete some of those loops, and presto, your app is significantly faster -- everybody will think you're an optimizing genius.
Be careful to include some calls to rand() or similar in your loops, though, otherwise the optimizer in your compiler might screw you over by removing the loops in v1.0, denying you your speedup in the new version.
I don't care if it's 90,000 hectares. That lake was not my doing.