Technology Development and the Long Game
Do you remember a time when, in order to get a new version of the software, you had to wait for new diskettes to come in the mail?
The first company I worked for professionally after college was ParTech, Inc. developing their cash register software, and we used 3.5-inch floppy discs to install our software onto a machine. Since we developed on Windows computers, we either had to transfer the files via FTP or use a floppy drive attachment to get the new software onboard.
Updates to the software happened after the nightly close of the stores, and only if you shipped out new discs. This meant that any version of software you put out had to be pretty good because it might be a long time before another version came out, and new versions were hopefully limited to a few new features.
Quality Assurance (QA) on a new version could be extensive, and the discs that passed could be cloned to send out to all the sites.
Today, with the Internet and Software as a Service (SaaS), it’s very tempting to be “fixing” things at the same time you’re building new things and having the requirements constantly change because, after all, it’s just a deployment on a web server, and we control the server– everyone can get the new version automatically!
So we’ve come up with methodologies like agile, scrum, and other means to make it so that we can do a quantity of work over short periods of time to get the software to our servers– and therefore the customers– as quickly and efficiently as possible. But this flexibility has led to less planning and designing (in practice) than we used to have.
When you had to wait hours for a compile, you made sure you did your best to check things over ahead of time. When you had to send out discs, you checked that release well because it’d be tough to get a fix out. Now, if you get a bug, you can just recompile in seconds and push something out. And everyone knows this.
Therefore, Product Management can be tempted to give half-baked requirements, or change them frequently, Product Development can build whatever just meets the requirements, or say that something else will come out as a patch, and the customers bear the outcome.
Let’s all challenge ourselves to be better. To put in the time necessary to get our parts right and not go forward without something we know is the best we can do.
