Is it sometimes reasonable to cut corners and expect to re-write software in a couple of years? [duplicate]

Question

I work for an organization with one developer (me) and one DBA. When I started, the previous developer had developed applications that had bad architectural practices and it was getting and more time consuming after a couple of years to add features, fix bugs as the story usually goes.

I came in and started re-writing a couple of apps from scratch. Now being the only developer, it's taking me quite a while to stick with TDD, do good UX, good architectural principles, create common libraries for business logic as it's used by many applications, etc.

I'm wondering if in an environment like this it'd be more feasible to cut corners and churn out web applications (I'm not sure about desktop applications) with the intent of re-writing them every 2-3 years. I mean cutting corners in things like unit tests and architecture. I'd expect such applications to be hard to maintain over a long term, and that'd be ok, because we'd just rewrite from scratch and copy and paste any business logic we needed to carry forward - as long as the requirements, documentation, and the data modeling is solid.

Anybody see any pitfalls to this? I guess it wouldn't be good for my career in the long term, but from the organizational perspective, I think it makes sense. The pay is kind of low because they're constrained by budget (govt. job) and I think the developer wouldn't last more than 2 years. I'd really appreciate any insights.

Answer 1

Yes, there are definitely situations where it makes sense to create some down and dirty "throwaway" code with the intent of tossing it after a couple years and starting over. Perhaps your company is trying to quickly prove out a new business model and want to get a sense of the market reaction to a "test product". Perhaps there is an untapped market and getting a product out the door (time to market) trumps concerns over longer term cost of ownership (maintenance).

But here's the important part: as a programmer this is not your decision to make. The above are business reasons why it might be feasible. Your job is to implement code against business requirements, and those business requirements include architectural qualities such as maintenance cost, time to market, scalability, etc. There is a balance to be struck in time to market vs. cost of ownership, but they play against one another and it is not a one-size-fits-all answer. Your job is to raise these points to the business, try to do your best to highlight the different options and different resulting costs and times to market, and then act on whatever business decision is made.

In your specific case you seem to be deciding to rewrite the same business logic over and over again to save on app time to market - I don't think this makes sense in the general case. It is almost always very difficult to extract all of the business logic (remember that one required field that you highlighted with a red border in CSS rules - that's business logic from a certain perspective) and get it right again in a second app. I would lean toward maintaining the first app in this case.

Answer 2

After 2-3 years you will have an application into which you will have invested 2-3 years of development time. What makes you believe that re-creating it from scratch will take significantly shorter than that? Maybe due to more experience with the domain you can go down to 1 year, but that's still a very long time. What will you do while re-writing the app: tell your customers there will be no bug fixes and no new features for a year? It's not gonna work.

Answer 3

The pitfalls? You have an opportunity to create the work environment of your choice. I don't see how creating code that is not easy to add features makes your life any easier. Most devs despise and look for answers on how to fix poorly developed software.

Your predesessor chose to use bad practices and you want to do the same. It's obvious your company has no idea how to create and manage software or developers.

Unless you are being pressured to deliver changes faster regardless of the quality, I don't see why you would want to take this path. Write code you can be proud of. If the company doesn't appreciate this, you seem to think your stay is temporary anyway. Life is too short to write bad code.

Edit - I'm not arguing you have to write the world greatest code (As MichealT pointed out), but take every chance you can to do your best and continue the process of improvement.

Answer 4

I'm wondering if in an environment like this it'd be more feasible to cut corners and churn out web applications (I'm not sure about desktop applications) with the intent of re-writing them every 2-3 years. I mean cutting corners in things like unit tests and architecture.

I'd agree that it is tempting to cut corners and churn out web applications ever 2-3 years though I'd wonder if you've tried this cycle a few times to see what happens? The cutting corners is a contributing factor of what leads to the issues you are facing now, you do realize, right?

I'd expect such applications to be hard to maintain over a long term, and that'd be ok, because we'd just rewrite from scratch and copy and paste any business logic we needed to carry forward - as long as the requirements, documentation, and the data modeling is solid.

Have you run into cases where some of the business logic that was handled by default behavior gets buggy in a new version of the language or platform because things were upgraded? What kind of change over would you have for users of the application? That may be the more important point as while you can re-write the guts of the application, if the data model changes a great deal, how well do you handle converting all that data?

I'd also question if after a couple of rounds of this, how well is anyone keeping all the requirements and documentation up to date which while you have an "as long as..." that from some managers may not be that high of a priority and thus we have more problems compounding.

---

At one of my previous jobs, we spent 2 years getting the first phase of a new content management system running. In that case, to try to re-write it every 2-3 years would not work well for the company paying millions of dollars for the project if one adds up all the licenses, labor costs, and other things. Thus, it can be worth considering how long does a re-write take as if it takes a few years, then you're forever dealing with parallel systems, no? There's a current live system being tweaked and the next one still being built at any given point in time. I doubt you intend for this situation but it is a way to interpret what you are doing here.

Joel Sposky did write about rewriting software some years ago that may be worth reading to see how applicable are his points on this.

Answer 5

Firstly, that's how the Y2K bug happened. But let's continue.

You are going to drastically overestimate the amount of time until a corner comes back to bite you. If you cut a corner, do you think it's going to be years until you have a problem with it? Or sometime a few days later, when you do a bug patch on code you thought you wouldn't have to touch again? Doing things wrong means you have to spend some time each day worrying about it.

But more generally, it sounds like you've framed this in a very self-harming manner. Are you under pressure to get things done "faster" and cut corners? If so, then you need to improve your business skills to the point that you can make the case to your manager that "cutting corners" is not the fastest way to get things done. Are you under no pressure at all? Then what do you possibly have to gain out of cutting corners? This is a very YOLO way to live, where you assume that "I'll be dead by then!" and... well, are just alive and in bad health, and haven't particularly enjoyed life in the meantime. Is it really fun for you to cut corners? Probably not. It actually sounds like it's making you unhappy with your job, when you could spend the same time being happy with your job by doing a good job at it - and finish with a much better resume and skill set. So I strongly recommend against this strategy, if you can call it that.