39

When I first started programming, I assumed that I would one day get to the point where I would start a project by sitting down and sketching a UML diagram of all the classes, then pretty much stick to that. I have now been programming for a couple years and it is not turning out that way. As I go through a project, I am often saying

  • "Hey, I need a class to do __. I didn't think of that before."
  • "Wait, this function should really be in that class instead of this one. I'll move it over."
  • "This should actually be two classes instead of one. I'll split it up."
  • "I should make these three stand-alone classes all inherit from one abstract class."
  • Etcetera, etcetera.

Is it a bad sign that I am often redesigning like this as I go along? Does this mean I'm a poor programmer or is this normal?

juicy lucy
  • 521

7 Answers7

41

This is a normal part of development. Two of the core tenets of Continuous Design is that:

  1. You are not omniscient, you can't know the whole system from beginning to end before you start.
  2. Design is not static. This is more prevalent when a project has been in use for a long time and the problems it is now solving are not the problems that it was solving when it was first written.

My personal view on the matter is that you should have a good idea of the macro design, but allow the micro design to evolve. Another way of expressing it is that the high level design (which is as far as I go with UML/modeling tools) will most likely remain pretty static over the life of a project. The detailed design of which methods do what and the class hierarchy need to be free to be malleable.

When you really don't know a lot about the problem you are solving, you'll make a lot more initial mis-steps. However, after you've worked with it long enough, the overall design will start settling in place and the refactorings you are talking about are all that will be needed to keep the code tidy.

Berin Loritsch
  • 46,104
  • 3
    +1, this is why I always cringe when people speak of serializing objects into a database --> and what if tomorrow your class has been exploded in multiple parts, how do you deserialize without keeping the old code around ? I much prefer the Protobuf alternative (dedicated classes for storage/message exchange) where your core classes are free to evolve, and you just need to adapt the serialization/deserialization layer. – Matthieu M. May 10 '11 at 18:18
  • @Matthieu - you write a database migration. This seldom takes more than an hour to write and test. Ruby on Rails has a very nice facility for database migrations. – kevin cline May 11 '11 at 03:20
  • 1
    @kevin: we don't have the same databases I guess, mine contain a few hundreds of millions of lines. Migration is not an option. – Matthieu M. May 11 '11 at 07:02
  • +1 - being too proud/stubborn to admit you made a mistake is not a good thing. Some people see admitting your mistakes as a sign of weekness, but most will probably respect you for it, and certainly if your strategy for coping with a serious mistake is to deny that it's a mistake, that second mistake is very likely to be fatal. –  Jun 18 '11 at 07:16
12

What you are doing is popularly referred to as "refactoring". If you ever stop doing that then you are in trouble.

The fact is most code is complex and humans, even pretty smart ones, can't figure it out all at once.

ElGringoGrande
  • 2,913
10

No, you appear to be following YAGNI and refactoring from the examples given. Don't you think it is better to have this better solution and be able to do it than to just never think about something again?

Agile software development usually has practices to accommodate this that is quite different from the waterfall model.

JB King
  • 16,795
5

That's perfectly fine (unless these redesigns are always major overhauls, or rebuilds from scratch). Don't worry. It can be good to start with a UML diagram at the begining of the project, but don't carve it in stone as you will almost always discover that things change as you work. You may learn new techniques that you didn't know at the begining, you may want to imrove some features in ways that you hadn't though of during initial design, the business requirements change, sometimes there are unknowns during initial design that can only be accounted for later, etc...

What is important is to go and update those initial UML documents so that they reflect any significant changes in design, else future developers (including yourself) could end up very confused. This can be difficult, and often requires good dicipline (and time).

It's very very very rare to start with a design, and adhere to it 100% until implementation. I personally have never seen such a thing happen, except for very small and trivial programs.

FrustratedWithFormsDesigner
  • 46,235
  • 7
  • 128
  • 176
  • 6
    Step 1: Create UML diagram. Step 2: Write code. Step 3: Throw UML diagram away so that nobody ever sees it and becomes confused about how the code actually works. – kubi May 10 '11 at 20:34
4

What you're doing is perfectly normal (provided you're not completely starting over from scratch every time). I've been at this for over twenty years, and it's still an iterative process.

The only time you're going to be able to design everything up front and stick to it is if you're solving the exact same problem you solved last time, and even then you can probably find room for improvement.

John Bode
  • 10,856
2

I by no means am a highly experienced developer but I do this too. Over the last few years, my ability to mentally construct the necessary architecture has improved greatly. However, as I write a piece of software, no matter how much planning I do, there are always places that need a bit of redesign. Spots that I didn't realize I'd be repeating myself until the code is actually being written.

My point of this post is to say that I do everything in your list and I don't feel like those things are necessarily bad unless they are happening constantly and having a real negative effect on your productivity.

Piper Merriam
  • 121
0

That called iterative process and it's a basic concept in all modern software development techniques.

vartec
  • 20,806