19th-Century Tool Box Is Meticulously Designed to Hold 300 Tools | Tool chest, Tool box, StudleyCraftmanship to aspire to

One of my best customers called and asked me if I could fix an app. I knew and was friendly with the original developer. I had helped him with some code several times on zoom. He was new to MS Office development. While I’m always happy to help, fixing other people’s work isn’t something I enjoy. Ask yourself how many coders take the time to properly document or annotate their work? I write very straightforward and easy-to-understand code. If I’m guilty of anything it is that I don’t spend a lot of time optimizing my code. My first and primary objective is that it works. If it takes a second or two longer to run, oh well. I rarely have time to play with the code, I am usually under a deadline and it needs to get done. I have never had a client complain.
As the complexity of my projects have increased I have had to slow down to be certain to do things like minimize trips to the server and look for other ways to achieve faster execution. Still, given the opportunity I will write some rock solid simple code.

The client emailed me the app with the instructions to patch it. I started the process of understanding the code and to say that it was rough going is an understatement. In my humble opinion the code was needlessly complicated and flawed. It was what I call spaghetti code, jumping ball over. What is worse , extensive use of some complex use of ranges coupled with not respecting the concept of global and local had created a nasty bug that acted just like a virus and corrupted the app. 

I called the client and told him I couldn’t fix it and needed a complete rewrite. It would be a big job, so I told them I needed a premium rate as I had to put all my other work aside. No, I didn’t take advantage. They agreed. I heard through the “grapevine” that the app cost a fortune in developer fees and the client had quite a nasty blow-up with the old developers firm.

Over the next few days I learned the app had never worked and the person running the code and working with the developer said “scrap it”. There was definitely a lack of transparency.The client, the old developers firm and I held weekly progress meetings. It took a couple weeks but I got it done. My version cost less than a tenth of the original version. It’s been running now for a good six months without issues.

A couple of days ago, I got a request for another rewrite. This was a smaller project with the same developer. This time, the misuse of error handling had created a bug where the reports were wrong, and no one knew.Two exhausting marathon days later, I had rewritten the app. I was paid (always good) and left to think about it all. The moral in my mind is keep it simple. Writing ‘spaghetti’ code that is indecipherable does no one any good. It will come back to haunt you.Well-organised simple code like the toolbox above is a joy.