I frequently hear people saying â€œthe difficult problem in computing is Xâ€ or â€œnothing is hard in computing but Yâ€ for some value of X and Y. The most common one I hear is Phil Karltonâ€™s quote
There are only two hard things in Computer Science: cache invalidation and naming things.
I think that both naming and cache invalidation are hard but I donâ€™t think they are the hardest problems in computing science. Nor do I think â€œIs P == NP?â€ is the hard problem. It is certainly hard but it isnâ€™t all that important except for a certain class of problems. Maybe Iâ€™m doing the wrong things with my life but I can count on two hands the number of times Iâ€™ve run into a problem where the solution was a linear approximation or aÂ searchÂ in NP space.
No I think the big problem is: how is this going to change in the future?
Every design decision is informed by how much youâ€™re going to need to change the code inÂ future and in what ways it is going to change. Should you use dependency injection? The answer lies in whether you expect new implementations to be needed in future. Â Should you use Â a message based architecture? Well are other services going to be interested inÂ receivingÂ notifications in future? How about deploying your reports to the client or to the server? If the reports are going to change frequently then to the server but if theyâ€™re static then client deployment provides a better user experience.Â Even problems like designing for scalability are informed by a knowledge of just how much the application is going to need to scale in the future.
The worst part about this problem is that it is clearly unsolvable. All you can do is guess about how maintainable and future proof your code base needs to be and make a decision. Â No matter should you be tooÂ pessimisticÂ or too positive about your guess there is going to be a cost for guessing wrong. Iâ€™m a software guy more than a business guy so I think that the best bet is to guessÂ pessimisticÂ and build your application to be moreÂ resilientÂ to change. Business people might side with building the application as quickly and easily as possible because you donâ€™t know if it is going to succeed in the first place.
Make no mistake, it is aÂ conundrum. When you pay for senior developers and architects youâ€™re paying for people whoâ€™ve been around enough to make good guesses. In my experience good guessing more than pays for the cost of hiring good developers.
If you happen to come up with a way to tell the future and solve this problem then let me know. You could just let me know by sending me the winning lotto numbers for the next 5 or 6 major lottery jackpots.