Son: Daaaaad. Why do we park so far away?
Me: Because driving around for 20 minutes to save 5 minutes of walking is stupid.
I have worked at a variety of different types of jobs and companies over the course of my career. Some of it at companies that sell software. Some where the software group is a small part of the corporate whole. Others where the company offers a variety of services to customers and the software is there to support those functions and the customers almost never see or touch the software that is responsible for the goods and services they are consuming. Given this variety of business models and the different types of needs software supports in these environments, there are some commonalities in building good software. Likewise there are also some commonalities in the types of corners that management and stakeholders will ask you to cut. One of those is the ability to properly administer the software on an ongoing basis. I’m going to talk through some of those asks, why they are a terrible long term idea and how to push back against these asks and do the right thing.
Most people that have worked in the software industry in any capacity are aware that the screens you see and interact with are wrappers around code that does the interesting work and the inputs and outputs for that interesting work are stored on a disk somewhere. That somewhere is a file, database server or any of a host of data repositories.
With this deep knowledge of how software works, and in the interest to get the software “finished” faster, where “finished” is the minimum amount of work to get the mechanics of the feature in front of the user, you will at some point get asked to short change the amount of work on the administrative interfaces to properly administer and operate the software on an ongoing basis. These are many times deemed non-essential and will get thrown on the pile of technical debt to be looked at later. The line of thinking usually goes along one of these paths
- This is a one time setup. We don’t need to administer the software at all after it is operational.
- These updates happen infrequently at best and the data isn’t that complex. Why would we spend a week on a task that can be performed in 10 minutes and might happen twice a year?
- I don’t ever see the interface and you programmers are like wizards or something. Can’t you just go update the data flooble-flobbles later without taking the time to build an admin screen? My customers need this NOW! THEY CANNOT POSSIBLY WAIT THREE MORE DAYS!!!!
On the surface these all sound reasonable. Until they have been burned by the lack of ability to properly administer the software, especially in a situation requiring fast turnaround time (outages, unhappy customers, compliance issues, etc.) many programmers will say ‘ok’, wrap up the minimum to deliver a finished feature and then move on to the next thing.
So first thing, and this is the most dry and boring, is that a lot of research has been done that says that the most expensive, long term part of any successful software deliverable is the maintenance cost. There are papers on this going back to 1981 (probably even earlier…). This is the year Raiders of the Lost Ark came out for those of us that measure time in move releases. It often exceeds the original development cost. By taking shortcuts on the ability to manage and maintain the software you are guaranteeing this state of affairs. It’s like leaving all of your windows open in the winter in Minnesota. Yes, your furnace can work extra hard and keep your house warm, but why would you do this to yourself?
The infrequent update is, in my experience, the most seductive of the reasons people do not build out proper administration and make their software operable. “I can do this in 5 minutes, what’s the big deal?”. That is probably true, today, right now, while you are working on the feature. Or 10 minutes after you finished it. Somebody needs a small change? Just go update the 5 fields in the 3 different tables and *poof* done. And you don’t touch it for 9 months. A similar change needs to be made. Now what tables needed updating? Did I get all the fields? I hope I put all the right constraints in so changes that would break the system aren’t allowed to be committed. I think it’s good. I’ll make the change. Oh Fuck, it just crashed. This is of course all hypothetical and has never happened to me or anybody I’ve worked with.
As for impatient customers, I don’t know what to say other than they can wait. Especially if it’s the first customer. Imagine it IS the first customer. Just one lonely, somewhat vocal, customer. Let’s say you want to get your sales person or product manager out of your hair. You take the ten minutes to make the change and they get it to the customer and everybody is happy. Now imagine that this is the feature all the customers have been dreaming of since the foundations of the world were laid. Great. Suddenly ALL 1,000 CUSTOMERS want this feature enabled. That’s 10,000 minutes. Guess what you are doing for the next seven days? That would be 24 hours a day, in a row. Not seven working days. And that is the minimum, assuming you get the settings right every single time you make the necessary changes. Too bad you didn’t have something like a computer executing code that is really, really good at quickly and accurately repeating mundane tasks.
When you get these requests, the most effective means of pushing back is to clearly lay out the costs of not doing the work. The ask to shortcut this work almost always comes in the guise of getting the software out sooner and saving time and maybe money in the process. This is usually a very penny wise and pound foolish ask. Be very explicit about the cost, laid out in terms of the time and approximate dollar amount of your salary. Make it obvious that this is , in fact, a very expensive ask.
Sometimes you may need to add onto the estimate the opportunity cost of not doing the work. Because if you are saddled adding rows to tables, or flipping values in fields to make a customer happy, you are not working on new features or fixing high priority bugs. This is a real cost with a tangible price. At the bare minimum make it clear you will miss deadlines.
And, finally, if you keep getting stakeholders telling you not to bother, just write it anyway. That’s ultimately what I’ve come down to on many occasions. Have I gotten yelled at for this? Sometimes. Have I gotten fired for it? Not yet. Months later when the same changes needed to be made, or lots of customers needed the update, have I heard somebody say “I’m sorry” or “You were right”? Occasionally.
Please, please, please make your software operational and administrable. Your bosses will thank you. Support staff will thank you. QA will thank you. Your customers will thank you. Your colleagues will thank you. YOU will thank you. The thanks may be silent because these people will all be unaware of the unholy mayhem you avoided. You may just need to be content with having done your job and done it well.