From Anne Giles Clelland:
"Regardless of industry, your company is now a software company, and pretending that it’s not spells serious peril."
– David Kirkpatrick for Forbes
As a company founder, I feel fortunate to have had some software experience during dot-com. One of my top takeaways from that time – of which there are many, mostly bitter rather than sweet - I know what I don't know. When I have the expertise, I Do-It-Yourself, DIY. When I don't, I ask for help. Maynard Wiff was kind enough to answer my questions on blending a start-up's founding developer with new developers and old code with new code.
From Maynard Wiff:
Using configuration management (CM) on software is an engineering discipline that dates back to the dawn of the manufacture of interchangeable parts. For physical parts, a description or drawing generally describes the dimensions and important features, materials, processes, and so forth. In complex manufactured products, it's important to have the right part – and the right revision of that part – in order for the machine to function as intended.
Software needs the same degree of control. The problem with software is that it is hard to visualize. In the case of a physical part, one can often see the difference or at least measure some key dimension. It's harder to do with code. Nevertheless it needs to be done. With multiple coders, it's really important because one person's work can be affected by another person's work.
So, we need to define some things. Source code is the human readable language, like HTML or C or Python, etc. Object code is the compiled or machine readable code. (Not all languages need to be compiled, some are interpreted, but that's beyond the scope here.)
The "production" system is what the customer uses. In the very old days this was all there was. Soon it became obvious that having programmers work on the production system directly was risky, so "development" systems were created so programmers could try out ideas and build subsystems and systems. At this point, there needed to be a process to determine 1) what was in the production system, 2) what was in the development system, and 3) what was the management process to move code from development into production. Depending on the needs of a system or project, there might also be a testing system, with known data, a training system, and maybe multiple development systems. Each needed to have a defined purpose.
At times, things got mixed up. A library is where code is stored on a computer. Think of trying to manage a deck of cards, all face down, that have been sorted into suits in four piles. Leave the room for a while. When you come back they have been moved. How do you KNOW what is in each pile? (You don't.) So there has to be fairly rigorous monitoring and control over the code libraries. Today there are automated systems that do this, that can tell who "checked out" some portion of code, and who "checked in" some code. There are tools that will do line by line compares to expose the differences, and so forth.
Programmers always are tempted to shortcut the system! Let's say there is a simple fix to be applied. The correct process would have this be done in the development system, tested in the testing system, and then copied to the production system. This takes time! Much easier to just make the change to the production system directly, and catch up with the rest later!
This is one way uncontrolled changes get introduced into systems. My rule was that programmers never had access to the production system code. The only way their stuff went into production was through the process which was run by a different person. This is hard to do with a small team, however. It can be mitigated by using a good code and good version management system.
When you think it through it is just common sense. Whatever tools the programmers use are just that, tools. It is the management principles that are embedded in the tools and the surrounding process that are important.
Read more about Software Development on Handshake 2.0.