Onliem by Reinhard Liem | Is it good to work with a very bad code but on a deadline?

Is it good to work with a very bad code but on a deadline?

Well, we've finally gotten to a point where the recommendation engines in the products we use are reading our minds because I quite literally just argued with some higher ups at my company about this a few hours ago.

I work as a software engineer for a biotech company and sometimes the clients ask us to build custom software for them. The company I work for doesn't have a great system in place for software development. It definitely feels like this entire department is an afterthought for the company.

We are working with the healthcare field, so there's a lot of very sensitive information. Our clients for some reason always have the most insane, and demanding timelines. The feeling at the company is that the world is literally going to end if we miss a deadline by 1 hour.

Just for perspective, this was a $3.4 million app, and we were going to lose the client if they didn't like it. The two developers who were above me when I started both quit around the time I got the job so I was on this project all by myself, and it was technically my first job as a software engineer.

The higher-ups at the company promised the clients things that aren't even always possible. When I first started here, I had some time where I barely slept over the course of an entire month because I was working probably 14 hours a day for at least 3 weeks with no weekends. It was the most stressful month of my life but it got me an absolutely massive raise that I couldn't have anticipated.

Now I'm building the same app but for another client. Ideally, it would all be the same app but with different login credentials or a different URL. Instead, I was told to basically copy and paste the entire code base and then customize it to meet the new client's expectations.

So far, I've deleted dozens of components and thousands of lines of code and everything is still working as expected. Of course I've had to do quite a bit of refactoring - but because of the lack of sleep, the crazy deadline, and the changing demands- the code base was basically trash.

Today, I finally started to feel like this app is cleaning up nicely. Realizing how much I had to delete to get to this point, I couldn't help but bring this up to the director. I told her that under the conditions I was put in, I did some of my worst work and left the door wide open for serious bugs. I explained that this type of crunch doesn't benefit anybody. The client gets shoddy work, the developer(s) become miserable and burned out, the management gets stressed, and at the end of the day we are behind on other work, and the client gets a buggy app built like a house of cards.

At no point in this process where we ever allowed to be honest with the client. At no point in the process did anyone with a c-level executive status ever reach out to the department to ask if things were going well (it's a pretty small company but it still has a board of directors and everything).

This is the downside of working for a company that doesn't understand software development and this is a very good reason why you don't rush your software for the sake of deadlines. I feel like I rose to the occasion and I feel like I was rewarded for doing so, I also feel very fortunate that their software seems to be holding up just fine - but everything about this project was a complete disaster in every way.

I'm a very passionate software engineer. I'm going to do my job with integrity and I'm going to do a good job. I don't need deadlines to keep me focused and productive. I know that this is just a job for some developers, but for many of us, we want to do a really good job because we want to be the best engineers that we can be. I think that a vague deadline, and a few check-ins along the way are perfectly fine but I think that a strict arbitrary deadline is the dumbest possible way to build software.

- Robert Bass

Leave a comment

Please note, comments need to be approved before they are published.