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.

marked as duplicate by FrustratedWithFormsDesigner, gnat, GlenH7, user40980, Kilian Foth Jul 16 '13 at 7:19

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


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.

  • +1: Agree very much. In addition, I find it helpful to build some understanding of where the business is going, as you cant expect input for every small decision you need to make. – jdv-Jan de Vaan Jul 15 '13 at 19:11
  • @jdv totally agreed. I view the role of the architect as the person that develops this long term understanding of the business direction and translates that into balancing different quality aspects in technical implementations. – RationalGeek Jul 15 '13 at 19:30

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.


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.

  • From perl culture - Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won't want to say bad things about. Hence, the third great virtue of a programmer. See also laziness and impatience. – user40980 Jul 15 '13 at 19:37
  • @MichaelT - I don't know about any of that, but if you're given the choice to do your best, why not take it? – JeffO Jul 15 '13 at 20:43
  • 1
    @JeffO exactly - just giving a quote from perl culture about the importance of writing code that your successor won't use your name as synonymous with bad code (my previous place of employment we called that "Jim code" after two people named Jim who wrote questionable code - the key is to not have your code be such that people mutter your name when they find it). – user40980 Jul 15 '13 at 20:56

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.

  • Thanks @JB_King. I haven't tried this cycle, and so I'm wondering if anybody has intentionally tried this and how well it worked out. – Riz Jul 15 '13 at 18:17

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.

  • 2
    That's how Y2K happened because it is so much easier to only have a 2 digit year than 4? Memory may be cheap now, but certainly not back then. Working within the limits of the available resources is not a sign of cutting corners. – JeffO Jul 15 '13 at 18:46
  • 1
    @JeffO and no one imagined there was any chance this code would be running 30 years from the time it was written. – djechlin Jul 15 '13 at 18:48
  • I'm sure there was plenty of non-compliant code written within less than 30 yrs. They knew it was a problem that could be solved within a couple of years and delay the expense before it became an issue. They must have done something right because civilization didn't end as predicted. – JeffO Jul 15 '13 at 20:52
  • @JeffO the right thing "they" did was pull legions of COBOL developers out of retirement - the ones who were still alive anyway. The U.S. Department of Commerce estimated the cost at over $100B. Anyway, most of what I know about the history of this bug is word-of-mouth from software instructors (in industry, not academia) I've had so I can't cite much better than the articles I just skimmed to get those facts. And ultimately this comes down to the rather philosophical question of whether not worrying about something and dealing with it later counts as masterful prescience, so, TTFN. – djechlin Jul 15 '13 at 21:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.