Works on my machine! Notes to my younger self.

Works on my machine! Notes to my younger self.

Thanks for that, good to know – Works on my machine! It’s such a common issue, hey lets ship your machine then 😁 How did we get to this situation. A lack of Ownership & Trust, that’s what! Part 3 from my series on the talk I gave at React JS/Finland. You can watch the talk directly here – https://youtu.be/zE8PDM_7xoQ?t=11404 This part covers my discovery that coding, isn’t always about coding. Read on…


For this one, I need to set the scene to highlight what I did and why it was wrong. Being more experienced now, I certainly wouldn’t have done what I did all those years ago.

The story

I was in a new role, one the main reasons for me being in that role was to fix an application that someone else had created that wasn’t functional. This application was created by a web developer who hadn’t written any web applications before. The process of designing/creating a web page is drastically different to creating a web application.

So I come in to this role, get shown the application, asked my views on it and how to improve it. After a while digging into it and running it, my conclusion was that I needed to re-write it from scratch. So that’s what I said. Like would I not say that – after all that was what was needed!

The answer to my request was a No. As it was my manager that said no (also the same person that wrote it) I was OK, fine I’ll get to work with trying to fix the issues. And yes I did improve it, I got it down from rendering a view in around 2 minutes, to being usable in under a second! I was like brilliant! Every time you make a large leap forward in getting that time down was like a huge win. So all was good – yeah?

No it wasn’t all good

I’d gotten the app down to an acceptable speed, pushed to production, then got the client to use it. They were still not happy? Why on earth were they not happy. It worked just fine (on my machine!). Anyway after a call, I go up to the clients office (for the first time), and within moments of being in the office it was clear why they still had issues. Their machines were archaic, super slow, well out of date machines. There was next to nothing left to optimise now, not a great situation.

What went wrong?

Firstly I should have understood that even though the guy that created the application knew it was rubbish, it was still his rubbish. It was his personal thing and as such someone coming in and suggesting it be started from scratch wasn’t going to fly. People don’t like to be corrected, even when they know that they are wrong. It’s human nature. You have to work at providing the evidence in a clear and balanced manner. Not just – it needs scrapped. Must understand the human element of coding.

Secondly, I should have found out what the client wanted. I should have found out what type of system the user was going to use the application on. After all the first pass of the app was out. The client may have loved it’s look and feel, or equally they could have hated it. Who knew? Not me anyway, and no one else seemed to care either.

STOP

Before doing any large scale of work, you need to stop. Never jump straight into the code, you will more often than not regret it in the long run. Unless your piece of work is for something short lived then you need to plan. I should have done an analysis of what was wrong with the existing app. The cost of fixing it, the timescales required to fix it, the risks associated with fixing it etc. On the other hand I should have done the same, but the risks etc for creating it from scratch using a new framework suitable for the requirements of the client.

With the existing, but broken app being considered a prototype and a stepping stone to making a better application, along with the raw data on risks/benefits etc given and shown to management (not just direct manager), then it would have been much more likely to have been successful when I suggested it needed to be redone.

Even on the basic needs that the users machine and monitors were so outdated, they needed a different solution. It would have cost the client a heck of a lot less to upgrade their PC’s and monitors, but that wasn’t an option. Why I’ll never know. Well I do know – but the reason made no sense, not a bit of it.

Key learnings

Ownership/Trust – I should have trusted in my ability to re-write from scratch the app to make it better. I knew I could, but when it came down to it I still didn’t have the belief to force my opinion to re-write it. Documenting the risks/benefits would have given that mental safety net, as carrying on with the old one wasn’t a viable solution at all.

Know your customer/client – Learn what the client has and what they use. Far too often I hear, it works on my machine. It needs to work on the clients machine.

Stop – Think about why you are doing something, what’s being planned, where is the future of the code going to be.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.