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.

Happily Waiting for Reports, Not!

In a former life I was a user in between stints as a programmer. Although I would say the experience taught me humility and respect for those programmers who I requested things for, I would be lying. Every time I would ask the programmer why this report was taking a lot of time, the response would invariably be: "Do you know how much data you are requiring me to sort through to get you what you wanted?" Of course, I played ignorant and said: "It just a few million records, it should not take hours."  The next reply from the programmer was: "If you think this is so easy, why don't you write it yourself!"

A year ago I was helping out on a simple report that should run in a few minutes. It took 1 hour and 40 minutes to run an accounts receivable aging against 2 million plus records. First I looked at the select and found it was taking about three to five minutes to get all 2 million records. I changed the select to use alternative keys and reduced the criteria to select against.  Those coding changes reduced the select time to under 3 seconds.

The code that processed the data was building JSON arrays that are passed on to the open source report writer from Eclipse.org called Business Intelligence Reporting Tool (BIRT). Building those arrays took about 1 hour and 30 minutes using a standard UniBasic code structure of appending to a dynamic array. I could not change the code to a dimensioned array because the size of the report varies from 1 pages to over 4000 pages. I tested it against my better judgement with a dimensioned array that would cover a 5000-page report and it did run in about an hour. 

There is a relatively new structure in UniBasic called UDO which stands for U2 Data Objects. I created the JSON arrays directly using the UDO function calls. The time to process the data was down to 50 seconds. Wow, that was more improvement that I had anticipated. Our BIRT report in production finishes in a little over one minute.

Maybe your programmer is right that it takes hours in today's world to process large amounts of data. Or maybe your programmer is using outdated coding technique that can be improved by being a lot more knowledgeable.