When Is Software Done?
I have some very exciting news. A piece of software I've been working on for over 2 years is released to the general public! This is a little exciting if it were software I'd been working on for some big company. It's very exciting because it's software I have been working on for my company. That's right! My company is ready to start selling software and start making money!
I'm not gonna use this blog post to talk about my company and what it does. You can read about that in our press release. Instead, I'm going to talk about the software industry and the concept of done. Because, as with everything, it's more complicated than it seems.
I'm not gonna use this blog post to talk about my company and what it does. You can read about that in our press release. Instead, I'm going to talk about the software industry and the concept of done. Because, as with everything, it's more complicated than it seems.
Software is never really done
Actually that's a misnomer. Software can really be done. But done is sort of a quantum state--there and not there at the same time. First and foremost, anyone can understand that software that works is complete. If the software's purpose is to process a credit card, if the credit cards process correctly then it's done, it's working. But even in that simple example you can see how modern society doesn't end there. There's constantly changing regulations on how the card has to be processed. There's new security features like chips that we need to handle as they come out. Different companies will change the way they format the data in their magnetic strips. And that's not to mention the fact that there's always new and different banks and credit card companies that you'll need to deal with.
But that's really the problem isn't it? We perceive done software as this never changing stone that can do absolutely anything. The reality is, it does one thing--what it was programmed to do. The world around the software is ever changing. When new software comes out to make searching for information easier (aka Google), we begin to rely on that and we want software that can make our company appear at the top of relevant search results. The world around us is not static. Software is. For that reason, it's hard to make software that is done in a world that isn't.
But software really can be done
Software that does it's job well enough might never need changing. A great example is a 1980s computer still running HVAC at some schools. There are hundreds of similar systems out there. Examples of done software can include things like the pipe command in linux, or the dir command on windows. This software hasn't had a need to change in a long long time. And there's a reason for that.
Software that only needs to do one thing can be done
If you can clearly and completely define a single thing that the software needs to do, it will be finished. The important part of that sentence is completely, because "process credit cards" is not the full definition. There's reading magnetic strips and chip data. There's encryption and decryption. There's integrating with varying credit card companies. There's keeping up with industry regulations. And note that each of those things are not complete definitions either. Chips and strips have varying data formats that change by company. Encryption and decryption change every other week as someone finds new ways to make things more or less secure. "varying" credit card companies is it's own bag of wax. And regulations don't even have a reliable way to be discovered by lawyers, let alone a software developer.
Integration is a dirty word
The biggest problem with the concept of done software is more subtle than it seems. Integration. Integrating your software with someone else's software makes the two pieces of software into one piece of software from the done perspective. If your software is done, and they change theirs, then your integration fails and you have to change it. So, the second you want to integrate, you introduce a huge exponential factor that makes finishing your software harder.
Changes bite hard
Even then, if you think about this in terms of two simple pieces of software this is understandable. But the second your software is something complicated that won't be done anytime soon (like credit card processing tools) then you create a scenario where your integration can't be complete until the rest of your software is.
But that's not even the worst of it. The worst part comes back to what it means to be finished. Software that you start working on before it is completely defined will take longer to finish than it would otherwise. And this is not what most CEOs want to hear. In manufacturing, the sooner you start on a product, the sooner it's finished. In software this isn't always the case. If you change your mind halfway through, you can completely change the way the software needs to be written.
More often than you might think, what appears to be a subtle change can be nearly impossible for software that was built with certain conditions in mind. A common comparison in the software world is a house. If the customer says "we're going to live in Florida" then the house designer might do things like lower the roof angle since snow won't be a problem but hurricanes are, and replace the frame with hardier wooden beams to resist the extra moisture in the air. If the customer makes no other changes to the design except deciding to live in New York instead, the frame and roof, and various other bits, have to be completely changed. And those changes result in a very different house in the end.
I can't tell you how many meetings I've been in where software developers, seeing the dangers of change, try to get clarification by asking something like "What if the user has two middle names?" only to be dismissed by management with "That'll never happen". Then, having structured the database and apis around this particular situation never happening, they have to account for it at a later date when "never" turns out to be "rarely". I always advise my co-workers to be careful about these situations.
Realistically, you don't usually want done software
In the end, done is not what we really need. What we need is functioning software. If it works for the moment, we can let the developers keep working away at fixing it, improving it, and adding more features and integrations as we need them. This is why Agile is so popular in software development these days. Most companies have accepted that diving into having their own software developers is not a temporary investment. They are going to keep them around forever as the company's needs grow and change. Because the world is changing, so the software must also.
Take my recent release as an example. This software is functioning, and it's doing so well. It's brilliantly effective at doing it's job, but it's job is complicated and ever-changing. The mortgage industry is inundated with ever-changing regulations, and we're working our way through dozens of integrations at the moment. So we'll continue to work on improving and integrating this software for years to come, but it works! It's out there! And it's ready for your company to use NOW!
And that is a wonderful feeling.
Comments
Post a Comment