I’ve been on both sides of the stick in software development. I’ve been a developer, trying to crank out a feature, and thinking “Geeze, I should be able to do this faster…” and “Wait, you mean this API doesn’t do this for me already??” I’ve also been a product owner, wondering, “Why in the world is this taking so long? It’s just a form!” The sad truth is that even a seemingly-simple problem in software development can turn out to be a serious can of worms. Why is that? Well, because the devil is in the details, and there is no such thing as a “solved problem” in software development.
.jpg)
[more]
Allow me to explain what I mean by a “solved problem.” By this, I mean a problem that, when confronted by it, we can immediately say, without any hesitation, consideration, or qualification, “Oh, you use X to solve that.” Can we truly say that for anything in our industry?
Most applications have the same fundamental needs: a UI, data storage, and (probably) communication. If I say, “I need to allow users to enter enter logs about widgets,” can you immediately say “the best choice for that is X?” What if I say this instead: “I need hundreds of users on various devices to enter records about widgets, about 100 per minute at peak, and we’ll need to be able to re-retrieve those. Reads will be much more frequent, about 1,000 per minute.” Can you pick what the best solution is yet? What if I elaborate further? “And the UI needs to update in real-time as users change the data, and all our mobile users will be on Android phones.”
Off the top of my head, I can think of a slew of technology combinations that could do this. And with each of those, there are probably many ways (approaching infinity) that I could implement the final solution.
And none of them are perfect. You could argue for, and against, each of them. Each will have tradeoffs. No matter what I choose, at some point, that choice is going to cause me pain, and probably not in small measures.
As a friend said, “You pick your poison and learn to live with its inadequacies.” I think this is quite true. Every tool, every technology stack, has not only strengths and weaknesses, but certain landmines that you just learn to step around; limitations you just learn to live with; and unsightly warts that you eventually just ignore and pretend like they don’t exist.
Why is this?
Why does it seem as if no problem within our industry is actually solved yet?
Why hasn’t one platform or technology stack won out? Why hasn’t something as “trivial” as ORM been done better? EF has strengths, so does NHibernate, and both certainly have weaknesses. Neither one has solved the problem. Micro ORMs are no better. They have strengths, but again, they also have weaknesses. Raw ADO.NET or database calls? Sure, there are times where that works, but there are plenty of reasons not to go that route, too.
Even memory management, MEMORY MANAGEMENT, a foundational piece of almost any piece of software, isn’t truly a solved problem! We have automated garbage collection, but guess what! You can still easily leak memory in a garbage-collected environment. And automated garbage collection has its downsides! Again, there are tradeoffs, pros and cons, to how we deal with memory!
Is this an industry where truly solving a problem is impossible? Is a perfect solution forever unobtainable? Is this the case in other fields as well?
Maybe I’m over-simplifying, but if I say, “I want a house like this,” a contractor seems to know exactly what to do to facilitate that. They don’t discuss trade-offs. It’s just common-sense: you do these X things. Sure, they may offer options on aesthetic things, and I suppose you can opt for various types of insulation and what-not, but most of those choices come down to price and what you can afford. They aren’t, “Oh, if you pick this type of insulation, your house will stay warm in winter, but if it rains, well, you’re going to get wet and you can only have a one car garage that will only accommodate foreign-made cars…” Again, maybe I’m oversimplifying things, but that seems like an obvious industry where there are indeed solved problems. Maybe solved problems exist in this industry, too, and maybe I’m just taking them for granted, but it doesn’t seem that way most days.
Will we ever hit that point in software where we’re building solutions up from solved problems, or will we forever be working with partial solutions, building houses of cards out of cards that are missing pieces or that burst into flames if they touch the wrong type of other card?
Maybe it’s an artifact of what we do. We build systems in a virtual world that is not governed by fundamental, unchanging rules. We don’t have “physics” constraining us, not at the level that most developers typically work, anyway.
Maybe it’s because the problems we solve are just that complex.
Maybe it’s an artifact of our industry being relatively new. Humans have been building physical structures for a loooooong time. We’ve been building software systems for what, 70-something years now?
Maybe we’ll eventually build tools and develop techniques that allow us to solve problems quickly, reliably, and predictably.
But we’re no where near there yet.