How to develop unsupported software

Original author: Greg Jorgensen
  • Transfer
I get paid to repay someone else’s technical debt. In my work, I see a lot of difficult code support, and again and again I see many problems that could have been avoided.

I specialize in debugging, fixing, supporting, and expanding the functionality of old software. My typical client has a website or application that more or less works, 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 running out of budget and deadlines. Usually this situation is accompanied by a list of missing features and bugs.
My typical client usually talked with other programmers who recommended discarding the existing one and starting development from scratch. Most programmers do not like support for code, and especially, they do not like supporting someone else's code.

When writing code, programmers often ask the wrong questions when they talk about further code support — see Matt DuVall's “Myth of Support” article to see 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 last few years without a version control system. When you are not using version control, the next programmer will need to find out which files are part of the current system and which are outdated or backups. 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 Damaged-Oriented Programming” .

Customize your development environment. As strong as possible.
Do not make it easier for the following developers to get started with code. Require specific versions of languages ​​and utilities, and do not forget to make sure that they conflict with the versions that come with the operating system. Set up 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 for replication of your development environment, do not worry about writing documentation - everything will be intuitive anyway.

Create the most complex build and deployment system
For a website, deploying to a test or battle 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 sharply turn around and build the most complex and bizarre build and deployment systems. This is one of the untraceable things that programmers do without the supervision of the client or PM (or without understanding them), so it easily gets out of control. When you chain 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 a test / intermediate server. Instead, use secret logins and secret URLs to test new features. Mix test data with real data in your databases. Since you are not using code control, keep copies of previous versions just in case. Do not embed logging in 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 a better template engine, ORM, sort or hash algorithm. I scratch the back of my head every time I see comments like “faster than the native method” or “replacing the PHP library function, because the order of the parameters sucks”.

Add dependencies on specific versions of libraries and resources ...
Add as much third-party code as you can. Link as many dynamic libraries as you need. I saw code depending on huge external libraries, only to access one function. Modify the source code of third-party libraries so that they cannot be automatically updated to the latest versions, but don’t worry about branching or keeping your modified versions under version control. I can compare your version with the original one and figure it out.

... But do not protect or document these dependencies.
I receive important calls due to updates and upgrades more than for any reason. WordPress's seemingly innocuous updates, Linux updates, or the new jQuery release cause a chain reaction of crashes. 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 cutting edge
Every day, HackerNews and Reddit buzz about cool new languages. Try them at the expense of the client. Any decent programmer can learn a new language in no time, 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, various server configuration requirements are fun adventures and posts on StackOverflow. I really saw PHP websites with inserts in Ruby, because everyone knows that Ruby is cool and PHP sucks. Semi-trained caching, cropped Rails and Node.js projects, and especially NoSQL solutions (“They scale better!”) Is my bread and butter.

Where are the programming tips?
It’s not so noticeable if your code is perfectly object oriented or brilliant and functional - because programmers almost always see the spaghetti code that they need to support. I am good at using diff, grep and Ctags, code tracing, refactoring and debugging. I understand the code. It is still difficult to work with the finest, most elegant code 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 at the Hoarders House .

Also popular now: