How to develop unsupported software
- 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:
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.
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.