Making good software isn’t easy (or quick)
I spent a large swath of my IT career with one organization. When I joined them, it was as a programmer, predominantly using COBOL and IBM CICS to provide instructions for mainframes that were the size of a ’67 VW Bus. Over time, this organization decided that we would pull a 180-degree switch from almost 100% custom development to the exclusive use of purchased software packages. Despite the protestations of our end-users, that’s what we did.
I worked my way into upper management but maintained a belief that the better answer for an organization of their size (over 2,500 employees) was a balanced approach rather than an all-or-nothing of either in-house development or COTS (commercial, off-the-shelf software). I tried to find ways to convince others for many years. I spent a lot of time working on my own, learning, trying to keep up. Ultimately I made the organization’s first (admittedly horrible) website, installed the first-ever Linux server on our network, and pushed heavily for the adoption of open-source software when applicable.
Getting the organization back into development, however, seemed to be an insurmountable obstacle. I was only able to make headway when we installed Oracle database software which came with a rapid application development tool called Application Express (APEX for short). Like many such tools, it made getting off the ground a lot faster; however, it became time-consuming when we wanted to stray too far beyond its predefined scopes. Nevertheless, the fact that we could show results quickly allowed the door to be opened so that, once again, we began to consider in-house development as an option.
Fast-forward to now, years later, when I am leading a small development company as we create websites and web applications for today’s clients. When we started this adventure, I brought the mentality that I’d cultivated for all of those years: that we needed to find as many shortcuts as possible in order to deliver quick and inexpensive results. I soon realized, however, that what I really wanted to do was develop products about which I could be proud.
(Please note: when I say “shortcuts,” I don’t mean finding good examples on the Internet and modifying them to suit your needs… it would be a little crazy not to do that. And I definitely don’t mean avoiding frameworks like Laravel or Angular. I mean doing things like using a CMS to build a website for a client who doesn’t really need a CMS just so you can finish quickly. Another example would be bringing in some giant JavaScript library because you need one little piece of it that you could have taken the time to write yourself.)
There are plenty of ways to shave time off the process, but they almost always end up adding bloat to the final product… more code for servers to load, more time to reach the browser, more potential vulnerabilities in your codebase.
I, as an individual, and we — as a team — care about coding, and care about coding well. We want to produce products that are secure, well-performing, and that provide a good user experience. Guess what? That takes time.
There are lots of people out there who still want fast delivery at budget prices. I wish them luck, but they’re the clients that have taught me, as a leader, to say “no.” Some of them will be back, later, after some bad experiences; some won’t.
At the end of the day, what matters most is that we’ll have built a company that creates efficiencies in its processes but doesn’t take shortcuts with its products and services. As I’m almost 57, I can tell you, that’s more important to me than having hundreds of clients or a jaw-dropping bottom line.
Coding is a mentally-challenging activity, and writing good code — sustainable, maintainable, scalable code — is difficult and time-consuming. It requires that developers be given the space they need to exercise their craft, that interruptions are minimized, and, by all means, don’t impose arbitrary deadlines.
Whether you’re someone who manages projects that include development, a client who sometimes contracts with developers, or — like me — a developer who has spent a lot of time trying to make both of the aforementioned happy, I think it’s important to acknowledge that good software isn’t a commodity. Development is both art and science, and the type of software that suits a specific business need while being secure and easy to use will take time and intensive effort on the part of a cross-functional team to produce.
