Throw Away Projects

If there is one thing I hate to hear most of all in the business world, it's "I want you to build a quick and dirty application because it is going to be thrown away in 6 months". I have had this happen to me time and time again, and then the applications never go away in 6 months, they seem to live on forever. First of all, I hate doing things the wrong way, and second, I hate having people look at my code later and think that is the kind of programmer I am. 

The worst project I had like this was about 10 years ago. The CIO of the company I was working for called me into his office and said he needed a quick and dirty application built. He wanted it to read the emails from an inbox, and create a ticket in their help desk system. I started looking at how to connect to the exchange server and read the inbox, and I put together a pretty decent proposal. When I showed it to the CIO, he said no, he just wanted to me to connect using the local outlook client. He just wanted "Quick and Dirty". He said he had done it before using VBA, and it wasn't that hard. He showed me what he wanted, and I just felt like this was a really bad idea, but he was the CIO, and he had put his foot down. 

I built the application just like the CIO wanted. It had to sit on a client PC that was always logged in. The code was horrible, the methodology was horrible, and I hated everything about it. Of course after 6 months, it was still there. The new features that were supposed to be implemented in the help desk system were never implemented, and there was no talk of getting rid of the application. Even worse was every time there was an upgrade to the mail system or the help desk system, I would have to fix the application. The help desk system kept changing their SOAP API's, so it was always breaking. 

After about a year of using the system, the manager of the operations group started offering my solution to our global partners. I started getting calls from Germany, Asia, and the UK as well as other sites in the US asking how to set this up. It was embarrassing beyond imagination to have other developers looking at this source code knowing I wrote it. I started out every conversation by saying, "This application is total crap, do not judge my coding skills based on this because my hands were completely tied". I would then go on to explain how I would have written it if I had been given the choice. Most developers have been in the same situation, so they could sympathize with what I was going through, but it still didn't make me feel any better about it. 

That application ended up being used for over 10 years. They finally implemented updates to the help desk system, and then replaced it completely, but it took a really long time. This was by far my worst example, but in the past thirty years, I have had a number of cases just like that. Whenever someone says that an application is going away in 6 months, I know it isn't going to happen. If you make something that works, even if it doesn't work well, it takes the pressure off fixing the problem the right way. At the end of the day, you have to do what the people who sign your paychecks ask, but I try has hard as I can to steer people in the right direction. It doesn't always work.

Have you had projects like this? I would love to hear other's experience, so please share in the comments. 

Comments

Popular posts from this blog

Asp.Net Core with Extended Identity and Jwt Auth Walkthrough

File Backups to Dropbox with PowerShell

Dynamic Expression Builder with EF Core