How to avoid rewriting parts of an application

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

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.

Answer 5

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.

Answer 6

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?

Answer 7

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.