Skip to main content

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.

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.


Popular posts from this blog

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …