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."

Comments

Old news

[Pharmboy]

This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

Re:Old news

[lgw]

Not every programmer was around when C was new. Everyone needs to learn these lessons, and preferably not the hard way.

I'm mean, you'd think anyone starting a major project today would use version control, that shouldn't even be a question, right? Right?! Sigh.

Some of his other stuff on his page is quite entertaining as well, like this one on Abject-Oriented programming.

Re:Old news

[girlintraining]

This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

A lot of that list is pretty damn arrogant, or at least naive. Let's start with just the ones the submitter quoted;

Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features

If you're so well known you can dictate terms to your employer, then maybe you can get away with this... for awhile anyway. But most of us, who code for a living, have to do the best with the tools we're given. We can ask for a testing server, but whether we get one is another matter entirely.

As for 'secret logins' and 'backdoor URLs'... every login is supposed to be secret. If you can get a list of userIDs via any external method, that's a security risk. And as for 'backdoor URLs'... Not everything should be accessible to the google crawler.

and mix test data with real data in your database.

There's any number of failure modes in complex code in which shoving random inputs into it will cause it to break in unexpected ways that don't become apparent until properly-formatted data is submitted after. I think what the author was trying to say was not to put invalid data into a production environment on purpose; It might make the app shit a brick. Unless of course that's the only environment you have to test. See also: That 'routine backup' of the EBT system that caused 13 states' food stamp programs to die in place.

Don't bother with a well-understood framework, write everything from scratch instead.

Again, pure arrogance on the part of the author; 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. Because as most experienced programmers know -- well-understood frameworks also have a lot of extra features and bloat they don't need. See also: .NET

Add dependencies to specific versions of libraries and resources, but don't protect or document those dependencies.

Okay, that's just plain sloppy. Well, 1 out of 5.

For the icing of the cake, use the coolest mix of cutting-edge programming languages.

The choice of programming languages matters very little, except to those who lack the Tao of programming. For those who are not One with the code, who do not grok the larger patterns that permeate the spaces between that which only the machine understands, and that which only the human understands, the language choice is the difference between life and death. For those who have transcended languages... it is the patterns they seek to understand. The language will take care of itself. It's like saying "Love" in French, German, Russian, or English. It's the same damn thing, and it's possible to understand someone who loves you, even if you don't understand a bloody word they 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; And frankly... they usually do. -_- I've seen some completely hair-brained solutions that are coded in Perl, cgi-bin, bash, PHP, and little chunks of C here and there that work flawlessly and at great speed because the programmer took the best of each of those languages and leveraged them in the solution. Of course, for every good programmer who does this, there's ten more who tried the same thing and wound up with a pile of half-working shit, sooo.... YMMV.

Re:Old news

[lgw]

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.

Re:Old news

[girlintraining]

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.

You devoted considerable effort to coming up with a response. Yet you failed in every way to realize that the point being made was that good programmers often depart from guideline, and with good reason. If this was less a list and more an advice column, then I wouldn't have picked it apart. But it comes off as a "dos and don'ts" list, and frankly... such a list has neither educational nor informational value.

But whatever, if you want to continue down this path, okay then; Look smartass, you can't test a framework against your own hand-crafted code because you don't know how your hand-crafted code is going to perform until you build a prototype. So fucking duh, yes, the test happens after. And if you'd sat down on a whiteboard and stenciled out a block diagram of what your app, or at least the part of it you're working on, does... you'd already know which branches are going to be most used, and where special attention needs to be paid towards optimization. I already provided the caveat that where performance is critical. I'm not talking about business apps or databases when I say these things. I'm talking low level shit like how they're building switches that begin writing out a new packet while the previous packet is still incoming to gain precious milliseconds in high frequency trading. You aren't writing that with .NET or whatever framework you're upset I dismissed from consideration. PERIOD.

Also "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!" is about the most moronic thing you can say. Management doesn't consider your project resulting in piles of overtime "heroic". It considers you a poor performer and will be looking to replace you.

Perhaps you missed the part that the author of TFA makes his living answering panicked calls to

Yes, I got that. Wanna know something? Ask a police officer how honest the average person is. They'll tell you the average person is a slimy son of a bitch who's probably packing heat and looking to kill you and everyone you ever loved or knew. Wanna know why? Because that's their day in and day out experience. Ask a surgeon how to fix a problem, and every answer will involve a knife. It's the same everywhere.

You got suckered in by assuming one man's personal experience counted as fact. It doesn't. I recognize that in his particular line of work, he runs into these problems all the time, but that doesn't mean they were bad choices at the time they were made... it means that by the time it got to him, it had become a problem. And that's all.

Look, bottom line here is that when you code professionally, you are engaged in a massive balancing act between deadlines, error checking, other people's contributions, etc., etc. Coding professionally is an organic process, and while everyone knows what the best practices are (documentation, QA, modularity, readability, etc.) these are ideals to strive for, not things we can actually achieve on every single project. That would take a level of super-human ability that nobody yet born possesses. It's like the old adage in IT: "Cheap, Fast, Right. Pick any two."

My own experience/advice lines up with his rather well in this area, I'd say.

My own experience is that a mind intent on something refuses to admit to better things. In programming professionally, I've come to refer to this as target fixation -- they get tunnel

Great little article

[Anrego]

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.

Programmer not the whole story

[jasnw]

Yeah, yeah - code clean, test-test-test, document-document-document, have separate test/run machines that are configured the same, yada yada. This is all well and good, and any halfway-decent developer knows all this. However, software development is not done in a vacuum and each and damn near everything mentioned is involved in cost/time benefit analyses when crunch-time comes (which it always does). With some exceptions, when I see a company that's saddled with horrible old legacy codes that nobody can understand, often a large measure of this is paybacks (for not adequate funding and poor schedule planning) being the bitch that they are. How to do things the best way are well known, it's just that the best way is more expensive (in the short term, which is the only term business understands these days) and takes more time than the average business will wait. If the bottom line is get something done that sorta-kinda works as fast/cheap as possible, you get spaghetti code that even the guy/gal who developed it can't follow.

Bad management

[EmperorOfCanada]

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.

... says the self-taught programmer...

[MasterOfGoingFaster]

Hey, glad I could keep you in business.