Beware Of Writing New Software #

After writing software for 9 years, I have seen countless people putting a lot of effort on activities that were not important to their career progression, nor to the team effort nor to the business itself but sound very good and interesting in conversations with other software developers as if the statement “whoa, you guys are doing that!?” pays the bills.

Most of the time, these time wasters fall under the following categories: a big architectural drawing that takes forever and it will take forever times two to implement, a fresh rewrite of the project with very similar technologies or rewriting the entire framework your project is based on just to reach a similar output to what they previously had.

I consider those activities to be time wasters because it does not add any single unit of value to the end activity of the business. For sure there are some business in which an entire department is dependent on activities like that but that are a few exceptions and in the end, it is their business to build things like that. Like, for example, Apple or Microsoft who have to build big platforms which require big architecture, reinvent new programming languages with similar features or frameworks from the ground up that reach similar conclusions because those things will help their business by attracting developers to their platforms. 

Now, doing all of that for your SaaS or mobile app is a waste of time because the time horizon for these activities is so far in the future that your business might not even exist anymore. Of course, there is the argument for Salesforce, which is a SaaS, and for sure does all these big efforts and more but they do it because they have reached the level of being a platform, not a service, making these big effort activities to be a correlation not a causation of their success.

How big the business should be before these big efforts are worth while? Well I don’t know, but maybe somewhere in between Salesforce and Basecamp, which even as successful and big as it is, they have delayed rewriting, even small fragments of code, until it really, really no longer made sense. Here is an article from their CTO about still having, in 2021, jQuery in their codebase because it didn’t made any sense to rewrite up until then.

So then, what should smaller teams do? In my opinion, they should get better at making good decisions in the moment while having a somewhat vision of the future to where they want to get. Priorities and projects scopes change too much to have the ability to plan far ahead in the future and stick to it. If even Apple and Microsoft have many breaking changes in the first versions of whatever technology they release, how could you expect to not have them at a smaller scale that changes at a much faster rate.

Here is an alternative to the big effort activities. Instead of big architecture, take the time to implement the right way the current feature you are working on. Instead of a fresh rewrite, refactor those very smelly parts of the codebase and leave the rest as it is. Instead of rewriting the framework, learn to make it work for you and sometimes even slightly change your implement to fit the framework but never for a square on a round hole.