I'm working at a company on a project for their Sales department. It's my first professional programming job, but I've been coding by myself and learning for years. Part of the project involves taking some data and combining it with input to produce and graph. Then save the data...so on and so forth. So I wrote the code for this in a little under a day. The next day I showed my project supervisor, and he liked it, but "what if we had this", and wanted me to add something to the graph. This was not a huge change to the look or function of the program, but it drastically changed how I needed to be storing data, processing it, etc.

Again, it took me about a day to re-structure the database table, and rewrite the code basically from scratch to support this new request. I took it back to him again, and the exact same thing happened. He requested something else which drastically changed how I needed to process the data. So, I had to rewrite it again. Finally he signed off on it, and hopefully, I won't have to rewrite it again.

Just be clear, I'm not bashing my manager or anything like that. He's a great guy and the things he was requesting were not out of this world, they just were incompatible with what I had previously done.

I'm just wondering if there's anything I can do in the future to avoid complete rewrites. I understand making flexible code and was trying to do so, but I would just like to know of any practices or things I could have done differently to make this easier, so, in the future, I don't spend 3 days on something that should've taken 1.

  • 2
    What programming paradigm are you using? Procedural, object-oriented, functional, other? Commented Jul 11, 2017 at 19:11
  • 2
    To avoid rewrites - decouple your database and your application layer. It is not a simple concept to apply to how you write code. It is a complex concept that makes your code simple and adaptable. Commented Jul 11, 2017 at 19:26
  • 6
    Looks like the requirements were not clear or you misunderstood them. No principle or best practice can save you from re-do a whole application if the implementation was made over false assumptions. Before typing down a single LOC it's good to ask to the requirements "what If..."... Don't wait for the manager surprising you with a new what If.... Spending some time looking for the functional gaps will reduce the surpise factor too.
    – Laiv
    Commented Jul 11, 2017 at 20:30
  • 3
    Dependency Injection is your friend. Google it, and see how to apply it to your language/framework. It will allow you to write a much more modular code, which should decrease the amount of code that needs to be re-written when the requirements change.
    – Eternal21
    Commented Jul 19, 2017 at 12:23
  • 2
    While it might seem like lots of re-writes is a bad thing, the thing that really matters is how quickly you can respond to requests from your end users. While it depends on the complexity of the project, I'd say that 1 day is a pretty good lead time - you must be doing something right! In fact software that sees significant changes is a good sign - it means that its useful and is improving. Software that hasn't been significant altered for years is much more difficult to maintain.
    – Justin
    Commented Jul 27, 2017 at 9:36

7 Answers 7


As I commented, I have a strong feeling that the requirements were not clear the first time or probably you missed some important details.

Not everything can be addressed with better code, best practices, design patterns or OOP principles. None of them will prevent you from redoing the whole application if the implementation is based on false assumptions or wrong premises.

Don't rush into coding the solution. Before typing down a single LOC, spend some time on clarifying the requirements. The deeper you delve into the requirements, the more what if questions appear. Don't wait for the Manager to surprise you with next what-if. Anticipate things yourself. This little exercise can reduce significantly the surprise factor.

Don't be afraid to ask as many times as you need. Sometimes the trees (details) don't let us see the forest (the overall picture). And it's the forest that we need to see first.

When requirements are clear, it's easier to make better decisions during the design phase.

Finally, remember that the overall picture is a goal. The route to this goal is neither plain nor straightforward. Changes will continue to happen, so be agile.

  • 3
    This. This answer is the best way it could be put. Get those requirements before you do absolutely anything.
    – Rhys Johns
    Commented Jul 12, 2017 at 2:44
  • 1
    This is a good answer, but I have a nagging feeling that there is a better way to structure the application to make it easier to accommodate these requests. I don't believe any of so called "principles" floating about would help; the solution must be specific to the problem. Without more information, your answer is the only one that makes sense. Commented Jul 12, 2017 at 17:44
  • 2
    To build on top of this answer: It's important to also be agile about requirement gathering. Sometimes people get new ideas or remember something they forgot when they see the product. They may say: "I know I asked you to build this but it isn't what I meant" or "I know I asked for this, but now that I see it, I want something else." You can prevent this from causing frustration and rework by creating a quick and dirty "Proof of Concept". This can even be a mockup like a fake graph. It helps your customer think.
    – Akhil
    Commented Jul 12, 2017 at 18:21
  • 1
    Some may argue that abstracting the db from the code is not a must because "db vendors rarely change". I agree with you, but the point of my answer is: while gathering requirements, forget you are a developer, Focus on requirement gathering. Think like a manager, do ask like a manager. Don't rush into think like a developer.
    – Laiv
    Commented Jul 16, 2017 at 5:49
  • 1
    @Laiv 'Some may argue that abstracting the db from the code is not a must because "db vendors rarely change".' I think the real problem with that kind of thinking is that it's a rationalization, not a rational decision. The question to answer isn't 'how often do DB vendors change'. The first question is how much will it cost to eliminate DB lock-in and what will it take to switch if required i.e. cost benefit analysis. For example, I am rarely in car accidents but I always wear my seat belt. Decisions should not be made on likelihood/frequency of events without considering impact.
    – JimmyJames
    Commented Oct 3, 2019 at 16:32

There is no way to know that based on what you have given. It is more quick and dirty which is what you needed at that moment. But, then someone liked it and it's getting complex, so now you are starting to see that many problems don't show themselves until complexity sets in. There are so many different things that can be done it is simply overwhelming.

There's the old, "No Silver Bullet," and it's true. Again, there is no way to know what to do with full specs (or better ongoing specs for Agile), and the ability to use good programming principles and good designs. Programmers love to rewrite, over and over. I'm not saying you fall into this necessarily because of it, at this moment, is small.

Use this opportunity to apply some basic principles. You will find that they work but then someone will say, "Oh no, that's bad" or you will something else you like. You can't do it all on the company's money, but if they allow you time to explore, use it as an opportunity. There is always someone, some foundation, some person, that has the "best" way or some "new" way of doing things.

  • Good article that you linked.
    – SH7890
    Commented Jul 14, 2017 at 16:34
  • 1
    Good article indeed! I think is not the OP case but I could not agree more with the author.
    – Laiv
    Commented Jul 14, 2017 at 17:19
  • 1
    I didn't think it was one for one, but it read like it could be one day. Hopefully this will help the OP.
    – johnny
    Commented Jul 14, 2017 at 18:48

Your manager was most likely right in each of the steps you got through. It is not because he is the manager, but because he is considering the results and usability and probably number of previous dealings with customers or customers requests.

UI is hard stuff, usually, 5 people have 15 different views. And data and data structuring and data analysis tend to change that multiply by factor 10:). UI is like fashion, some combinations are cool, some are terrible or missing common sense.

Not to mention, that for example during LEAN process nothing is set in stone. You are experiencing something like iterative evaluation and during each step, it is little better or wrong path is avoided.

So simple answer is, that there is no such thing as no rewriting at all.


Iterative development (which is what you did basically, albeit one-day iterations) is often like this. Early attempts at solutions are often off the mark, and by gathering feedback, the system converges to a solution. I'll borrow the Figure 2.2 from Craig Larman's instructor material for his Applying UML and Design Patterns book.

enter image description here

At the start of a project, you learn to live with the apparent unstable versions. I'll disagree with the answers that say "you have to get more requirements early on," because that is Waterfall thinking. It's true you should strive to get as much as you can in terms of requirements, but for many reasons it's not possible to have complete and accurate requirements.

This is not to say you can't reduce how much you have to rewrite after you get feedback. One thing that has often been true is that human-computer interaction of software is very likely to change, because that's a hard part to get right the first time.

Think about Microsoft Word and how its data format (.doc) didn't really evolve much over the years. That's because a text document as a problem domain didn't really evolve much (a page is still a page, a paragraph is still a paragraph, etc). However, the user interface of Word evolved lots (and continues to). Code for the presentation or input tends to be unstable between versions, so it's best not to have the other parts of the system coupled to them directly (to insulate them from rewriting).

Software architectures that can separate presentation from underlying logic and data about the problem allow for less re-writing. Many software patterns such as Model-View separation came about because of people like you suffered over many re-writes, and sought out a better way.

This may sound very Buddhist, but you're fortunate to have suffered these re-writes! So many people learn about MVC patterns or other design patterns without having "suffered" the re-write nightmares the patterns are supposed to avoid.

  • I would prefer this answer to be the accepted one. Iterating towards a solution is better than trying to set up all requirements up front. Especially if whole application can be re-written within a day.
    – Euphoric
    Commented Oct 2, 2019 at 11:25
  • I’m sure the boss didn’t know what they wanted in the second iteration until the first one was complete. “Gathering more requirements beforehand would have been impossible.
    – gnasher729
    Commented Oct 5, 2019 at 11:04

I don't have an answer, so much as an exercise -- one that you will probably have to do in your own time, although depending upon your organization, you might be able to get permission to do it during working hours.

Redesign your first solution to do exactly what it did, but make it easier to add the 2nd or 2nd and 3rd steps. Don't add those steps, don't stub them out. Just create a solution that meets all of the original requirements but can easily be upgraded to include the new feature. Do the same for your 2nd solution.


Requirements change, that’s a fact of life. In hindsight: Could the first solution have been different so the total programming time would have been less? That’s what you learn how to do with experience.

That’s the first steep learning curve. When you manage this, there will be the second challenge: How do you handle changed requirements when users have stored a year’s worth of data that they don’t want to throw away?


From you story it is obvious that the requirements and preferred architectural decisions have not been communicated well enough. Hence one of you, or maybe both, are bad communicators.

It might be the architect as well, as some architects earn they high status for good achievements when programming alone, or great education (that is also most often about studying alone), or being the first developer in the company (obviously alone) and are not necessary good in communicating with the team. It is not uncommon for them to continue focusing heavily on programming rather than on documenting designs and supporting the team.

However also in this case you may try to compensate by talking longer, asking questions and taking notes. You may even write a small specification yourself and ask the architect to approve it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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