Thought technology can be a lucrative investment it depreciates quickly. If the only person or two that knows how to maintain a peace of that technology jump ship or get ‘hit by a bus’ then that depreciation happens all the faster and your investment quickly becomes worthless.
Beyond that if you are trying to build a scalable company as I am then you cannot be the only one that can maintain it. You need to be able to easily pass off the responsibility to maintain a project to other developers. If you can not you will never scale.
How are you protecting your investment by ensuring the technology is maintainable? How are you protecting your sanity by ensuring others can maintain the technology? Here are some things that I look for when building a software product.
Make sure no one in your team is building a piece of the puzzle in a language that is not a standard language. I look at what is currently the market standard. It might pay to be on the cutting edge of technology and chose the hottest new language or it might pay to use a language that a good chunk of the workforce already is familiar with. If only a handful of people are familiar with the new technology then you are going to have difficulty staffing the people required to maintain it or you are going to need to spend lots to train them in the new language.
Frameworks are similar to languages. They are libraries of code that make building things easier. I recommend sticking with widely used well documented frameworks. Don't let some designer reinvent the wheel by building their own responsive CSS classes or a junior developer that codes completely custom functionality that can be fulfilled with a simple mainstream library.
Not using Version Control is a rookie mistake. That is a complete deal breaker for me. Signing up for a BitBucket or GitHub account is a peace of cake. There is no reason for any modern developer not to use it.
For those of you that don't know what version control is it is like Google Docs for code. You need to know who made what change and when. If a developer comes in at a future date and can't figure out why a piece of code is commented out, deleted, or changed then they need to be able to go back and see what the last guy had changed.
Consultants unless on retainer are rarely vested in your project. They have a minimum amount of functionality they need to get in to your product but rarely are thinking of the long game.
Right now I have a freelancer that we are considering putting into play as the lead engineer on an project. I am hesitant because I can see that his interest are solely in hammering out the product, which is good, but its obvious he is not looking at it from an owners perspective. I need to know that once he has moved on to the next project a junior member of my team can maintain his code without needing to rewrite the code or pull me in to help him sort things out.
I am mitigating the above risk by pairing the freelancer with one of our junior developers and making it clear that the part of the freelancers responsibilities is to ensure that the junior developer can maintain the code without the freelancers or my help.
When a milestone is hit I aim to test this by assigning a mid level maintenance task to the junior dev and telling him to fix it. Then watching to see how far the junior developer can get without asking for help.
As you can imagine this will raise the amount of hours the freelancer can rack up because they are training the junior as well as coding but in the long term this will decrease the cost of rebuilding whatever rats nest might have been built.
Maintainability is the name of the game if you are investing in a software technology. If you cannot maintain it then its worthless. If your team cannot maintain it then you will get buried underneath the responsibilities of it and your business will never scale.
If you have any other suggestions please comment, email, or otherwise let me know. Its a challenge I and many others face everyday so any tips would be greatly appreciated.