Software is all about compromises

The client wants this function or the client wants that function. Your staff says this new cool JavaScript library will save you time and money. Your staff says if you buy this tool you will be able to do amazing things with it. You find out that you nobody on your staff has the expertise that you promised a client you could do. Let's take this one by one and see where they lead

This function the client says their software needs are based on what? It could be their competition has this. Or the CEO saw this in a premier business paper and tasked the client to get it done who called you. Whatever the reason, the software company must look at maybe this is a need that can be filled later without impacting the current timeline. Maybe if you don't architect this into the software, you will be delivery the software on time and in working condition.

Every tool that gets released the staff says the same thing: with this tool or software package, we will save lots of time and money. Anyone remember VB4, dBASE4, ACT2000, or some other acronym software that has long since died. Look for tools and databases that are stable that have been out for a while that may not be the best in class but they are backed by a good company and still have updates.

When a client asks you to write a PCL driver. Of course, we all say yes even though no one in the company has ever written a driver before. Then when the client gets the bill, you have to explain why it took many more months and cost 400% more. Only write software in your comfort zone you will be happier and your clients will be too.

No one can foresee the future yet, so it becomes apparent that you must look at each new idea with a grain of salt. Always, ask the stupid questions up front rather than explaining to your client that this project, database, and or tools you picked cause us not fit your client budget or timing.

Technical Debt: BS or Real?

What does this term mean and why should I care? "Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution." (See https://www.techopedia.com/definition/27913/technical-debt). You should care because the C Suite crowd thinks the code you created ten or twenty years ago suffers from this ailment.

First Technical Debt is not fixed by refactoring. If you are refactoring your source code which means you are restructuring the code without changing how the world interacts with it, does not have anything to do with technical debt. When source code is refactored your code should be more readable and more maintainable.

Second, Technical Debt is not Technical Savings either. It is said you can accumulate Technical Savings by investing extra time with your code to make those lines of code more readable and maintainable.

What a minute here? Both of the above paragraphs are saying the same thing with different words. Is Technical Debt just technical babble? Yes, in my opinion, it is just another take on spaghetti code, GOTO's in UniBasic, nested if's, and many other reasons why old code is not good code.

Just the other day one our clients looked at a routine that was written in 1984 (Great Year!) and thought it should be re-written because of the age of the code. When this code was written years ago there was no conscious effort to implement this quickly when there might be a better solution if the code was more thought out. This code was well thought out or it would not have lasted 33 years.

A lot of companies are saying you have accumulated Technical Debt on your source code to get your to switch platforms, databases or whatever. Stop letting those people tell you what your code is or is not doing when they do not have a clue what it does.