How to develop unsupported software

I get paid for returning someone else's technical debt. In my work, I see a lot of difficult to maintain code, and again and again I see many problems that could have been avoided.

I specialize in debugging, fixing, maintaining and extending the functionality of old software. My typical client has a website or application that works more or less, but whose author is not available. Business requirements have changed, and the software has ceased to satisfy them. Or my client has something that is “already finished,” but he broke up with the developer after the budget and deadlines were exhausted. Usually this situation is accompanied by a list of missing features and bugs.
My typical client used to talk to other programmers who recommended throwing out the existing one and starting development from scratch. Most programmers do not like the support of code, and especially, they do not like the support of someone else's code.

When writing code, programmers often ask the wrong questions when they talk about further support of the code - see Matt DuVall 's article “The Myth of Support” to understand how this happens. Below are a few practices that you need to follow in your projects, so as not to leave me without work:
')

Do not use version control systems.

I am always surprised when I come across large projects written in the past few years without a version control system. When you are not using version control, the next programmer will have to figure out which files are part of the current system and which are outdated or backed up. The next programmer will not have a single commit message or changelog to get the code history. I talked about how not to use version control systems in my article “Introduction to Damage-Oriented Programming” .

Customize your development environment. As much as possible.

Do not make it easy for the following developers to get started with code. Require specific versions of languages ​​and utilities, and remember to make sure they conflict with the versions that come with the operating system. Customize Eclipse, or Visual Studio, or vim like crazy, then write macros and scripts that work only with this environment. Do not store a disk image or scripts to replicate your development environment, do not worry to write documentation - everything will be so intuitive.

Create the most complex build and deployment system

For a website, deploying to a test or combat server should be one of these:

svn up git pull hg pull 

Programmers can argue about the simplicity and elegance of the code, and then abruptly unfold and build the most complex and fancy build and deployment systems. This is one of the untracked things that programmers do without the supervision of the client or PM (or without their understanding), so this is easily out of control. When you chain up eight different tools with different scripting languages, don't even think about doing the documentation.

Do not deploy test / intermediate systems.

The change on the combat system is exciting! Do not think about the test / intermediate server. Instead, use secret logins and secret URLs to test new features. Mix test data with real data in your database. Since you are not using control code, save copies of previous versions just in case. Do not embed logging in the code. Do not disable outgoing e-mails, credit card authorization, etc., during testing.

Write everything from scratch

Do not mess with well-known frameworks like Django, Rails, or CakePHP. You can write the best template engine, ORM, sorting or hashing algorithm. I scratch my head every time I see comments like "faster than the native method" or "replacement of the PHP library function, because the order of the parameters sucks."

Add dependencies on specific versions of libraries and resources ...

Add as many third-party code as you can. Link as many dynamic libraries as you need. I saw code dependent on huge external libraries, only to access one function. Change the source code of third-party libraries so that they cannot be automatically updated to the latest versions, but do not worry about branching out or keeping your modified versions under the version control system. I can compare your version with the original one and figure it out.

... But do not defend or document these dependencies.

I receive important calls due to updates and upgrades more than for any reason. Innocent-looking WordPress updates, Linux updates, or the new jQuery release cause a chain reaction of failures. Do not check in your code for a specific version or a modified version of your external resources or third-party libraries. Don't even add a comment to remind yourself.

Use a bunch of different programming languages ​​and stay ultra modern

Every day, HackerNews and Reddit are buzzing about cool new languages. Try them at the expense of the client. Any decent programmer can learn a new language in the blink of an eye, so if the next programmer who works with your code turns out to be a noob, then this is not your problem. Differences between languages, incompatible APIs and data formats, different requirements for server configuration are fun adventures and posts on StackOverflow. I actually saw PHP websites with Ruby inserts, because everyone knows that Ruby is cool and PHP sucks. The half-exhausted caching, cropped projects on Rails and Node.js, and especially NoSQL solutions (“They scale better!”) Are my bread and butter.

Where are the programming tips?

Not so noticeable if your code is perfectly object-oriented or brilliant and functional - after all, programmers almost always see the spaghetti code that they need to maintain. I am good at using diff, grep and ctags, tracing code, refactoring and debugging. I understand the code. With the most beautiful, elegant code, it is still difficult to work if there is no version control system, if there are too many dependencies and settings, if there is no test / intermediate system. It's like finding one clean and nicely decorated room in the “Hoarders” house.