Like it or not, we all have favorites and this rings true even in technology. Some people love JavaScript, Node and AngularJS and some people love Ruby on Rails and some people love to use Java with Spring and some people love .NET with ASP.NET MVC … etc … etc … etc … you get the point. Furthermore, some people love the hot new distributed architecture pattern, some people love the MVC pattern and some people love the spaghetti code pattern (if we can even call it that) again, … you get the point. People use what they like and/or know how to use and they get to decide what they like, and that’s OK. We can use anything to get the job done, and if it solves the problem then we can usually move onto the next issue at hand, regardless of the technology, practice or pattern.
Unfortunately, I’ve noticed a lot of people spewing nonsense about certain technology stacks/platforms/frameworks/etc. Using a given technology or stack or language or framework/etc is up to you, but hating on any given technology (and its adopters) gets you nowhere.
Furthermore, if the ridiculed technology is in production and is making money then it’s far better than whatever is sitting in your private project repo that has not even shipped yet. That’s a fact. Even if you wrote something and it is profitable and it’s in a different language, who cares? It works, it shipped and now you’re onto the next thing. No need to ridicule anyone about how your technology is better. I tell you what – higher level CEO’s rarely care that their system is written in Rails or Python or .NET. You know what they care about? Being profitable. Keeping people employed, motivated and happy. Growing the business. That’s what they are about. Technology is a tool.
Time for a story …
About 7 years ago I was working at a small insurance company in Minnesota. The client had a large application that helped managed specialty insurance policies/claims/etc for a large non-tech industry. Long story short – the app was a disaster and was written in a language I did not care for, but I did know how to work with. In my opinion, the application was poorly architected but it worked. The first glimmer of “WTFness” I encountered was when I had to add a single item to a drop down list. This took two full days. This is unacceptable in any technology. After about a month on the project, I was ready to give up due to frustration. I could not take it anymore I provided some unsolicited advice to one of the architects on the project. I said that the system needs to be put on life support and needs to be re-written because they’re throwing money out the window on small improvements and the project will literally drag on FOREVER. A rewrite of the system or its subcomponents might be a better option. What I didn’t see coming is what hit me the hardest. When he replied, he changed my career, and in turn he also changed my life because it altered the way I approached technology problems from that day forward.
He said something very similar to this …
“Donn, this app generates over 6 million dollars a month for the company. Without this app and us improving it, none of us in these buildings would have a job. The reason we are updating this app is because it is what keeps us employed and it is what keeps the company moving forward. We don’t have time to re-write it. Without this app, we have nothing. With it, we have 6M a month. Sure it was sub-optimally designed at first, but that’s all we could do at the time given our limited resources. Now, we have money to spend on fixing it and improving it incrementally. We have money to hire smart consultants and that is the reason we can afford to have you here. We have to fix it, we have to improve it, because now, we have the money to do so. It is what it is. It may not be fun, but it has to be done.”
That conversation was very humbling and to this day it’s something that resonates with me with every technology conversation that crosses my path.
It did not matter that the app was written in a language I did not like, used patterns that were bad in practice and was difficult to update. It was profitable.
The app was written in the best way possible at the time with the best tools available to those who were knowledgeable at the time. Sure, they may have made some mistakes and did things wrong or skimped in certain areas, but at that time it didn’t matter. They were trying to make a profitable product. Now they have one and it’s making enough money to bring in the proper talent to fix these pain points.
I’ve seen this same scenario replay itself over a dozen times in the last many years (and this happens a lot at startups in the Silicon Valley), but now when I recognize it I don’t carry any sort of spite for a given technology/language/pattern/practice/etc. I realize that this product was written with a particular goal in mind with a particular budget and time frame and most likely they had limited or no budget, a very short time frame and a very small staff when the app started. I’ve also seen this same story replay itself at the enterprise scale. Just because there are 5000 people at a company doesn’t mean that areas of the company do not work in silos. When it happens we have to look at it objectively and say: “It is what it is, but now how do we improve it.”
The thing is … Times change, languages change, frameworks change, best practices change and overall – technology as a whole … changes. This is a good thing, but as professionals we have to recognize when the right time to evaluate and implement a new technology is. We should not come in and bad mouth a particular technology because we don’t like it or approve of it.
We’ve all run into it as well … for example – Perhaps a client’s system is simply too slow with PHP and MySQL and we need more scale to grow the business. Perhaps the app is written in a way we cannot horizontally scale (this happens a lot). Maybe the app is slow because there are no indexes on the MySQL database. Already implemented those indexes and the app is still slow? Already fixed all the areas you can? Then at that time it might be time to evaluate NodeJS or Go or something else. So be it. There is nothing wrong with that. Just don’t throw the baby out with the bathwater simply because the bath water is murky. Realize what you and your client have and evolve. Use the right tool for the right job.
Regardless what it is, regardless how it’s written, regardless how it’s architected, regardless how it’s built, regardless how it’s deployed …
We’re professionals and we have to objectively look at each project with a fresh perspective in order to help move the client forward in the right direction regardless of the technology at hand.
It’s hard to determine when something is worth fixing, improving and redesigning vs starting afresh. It’s hard because sometimes in language X or technology Y solving this same problem would be 10x easier. This is when most of us get easily frustrated. This is the time when we need to sit back and evaluate the situation. When I get in the weeds and start over-analyzing a project I have to remind myself of this simple principle:
If its ships and it’s profitable – then it’s important.
While this may not solve your problem, it will help reset your expectations on said technology and align your current goals to that of the business you’re helping.
“and some people love the spaghetti code pattern” << LOL
>>Now, we have money to spend on fixing it and improving it incrementally. We have money to hire smart consultants and that is the reason we can afford to have you here. We have to fix it, we have to improve it, because now, we have the money to do so. <<
What bothers me is that if a client has the money to make a large number of incremental improvements, but each improvement's effort multiplied by the number of improvements is in total larger than the sum amount of time to rewrite, fully test, and implement the improvements upon the rewrite, it seems like a no-brainer monetarily to go with the rewrite. Unfortunately, due to the risk associated with a rewrite, that is such a hard sell to any businessman, particularly because no businessmen understands how ridiculously painful some software can be due to its poor implementation and absence of flexibility.