13

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? – Tulains Córdova Jul 11 '17 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. – StackOverFowl Jul 11 '17 at 19:26
  • 1
    You have to apply object oriented design so changes can be done in some places without having to change other places, but that is too broad for a single answer. – Tulains Córdova Jul 11 '17 at 19:36
  • 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 Jul 11 '17 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 Jul 19 '17 at 12:23
21

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.

  • 2
    This. This answer is the best way it could be put. Get those requirements before you do absolutely anything. – Rhys Johns Jul 12 '17 at 2:44
  • 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. – Frank Hileman Jul 12 '17 at 17:44
  • Well, I had the strong feeling that the problem was the one I commented because It was exactly what happened to me back in my early days as developer. I instantaneously translated phrases into LOC or modules, and when I had to change something was quite dramataically for me. Refactor over refactor every day or week. Not even doing my best with SoC, SPR, polymorphism,... Many of the conflicts I have had with changes were caused by my leak of overall vision. – Laiv Jul 12 '17 at 17:59
  • 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 Jul 12 '17 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 Jul 16 '17 at 5:49
4

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 Jul 14 '17 at 16:34
  • 1
    Good article indeed! I think is not the OP case but I could not agree more with the author. – Laiv Jul 14 '17 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 Jul 14 '17 at 18:48
2

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.

1

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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