Most agile people say big designs up front rarely pay off. You spend so much time doing design that you delay the opportunity of feedback from real, working software. But I sometimes do BIG DUF. It’s not that the design is big, it’s the problem that is big. So I need an up front big picture with just a few big parts.
It helps me conquer and divide.
That’s not a bad thing. What I find really painful is casting the design in concrete. When your design is cast, then your mental state is already cast in concrete too. And that means that it is a lot harder to do the right things. So, more gets added to the concrete slab and it’s real hard work to break anything off. When I have a BIG DUF, I often look at how to reduce it, rather than increase it.
I don’t think it’s wrong to have a BIGDUF, it’s worse if you have a BIGDIC (BIG Design in Concrete). That concrete block will hurt you later … a lot.
In other words, the size of a BIGDIC does not matter, it’s the rigidity that’s the problem (— That’s so lame, I could not resist!)
f3yourmind 
LOL! That last paragraph was funny! 🙂
Sounds like a potentially leaky abstraction to me.
Agreed. As the problem becomes bigger, a design up front becomes essential. For very small and rapidly changing applications however, the cost of a BIGDUF will outweigh its benefits (if the goal of the entire application changes).
It also depends on how big the project is you’re undertaking.
As projects become extremely large (more elements to manage), you’ll have to start introducing more formality in the process.
“small and rapidly changing applications however, the cost of a BIGDUF will outweigh its benefits …”
Of course, I’m not saying you shouldn’t do any kind of conceptual or rough design, in this case. Having no vision would be pointless.
[http://en.wikipedia.org/wiki/Big_Design_Up_Front].
@Michael. BIGDUF is not essential at any stage. It should be applied when useful and it should be malleable to the point of nothingness.
Also, I don’t like to confuse formality with management and size. The fact that many managers and developers think like that is real problem. I think creativity and discipline and maturity yield better results than formality.
Unless I completely misunderstand what you mean by formality 😉
Hi Aslam,
What I meant by formality was discipline.
I think you need to balance “freelance” with “discipline”.
I’d like to think of it as “creativity within the confines of discipline”.
The larger the project becomes, the more difficult it is to manage. In a more “crafted” environment ( i’m referring to the freelance extreme ), communication becomes tougher. You have more communication points in the team, and tacit knowledge becomes more difficult to maintain. You will need to bring in more discipline: more decisions / agreements to document.
I was referring to [http://en.wikipedia.org/wiki/Big_Design_Up_Front] on the definition of BIGDUF. BIGDUF is often associated with the Waterfall model, and therefore tends to be on the more “disciplined” approach to software engineering.
I was trying to make the link between using BIGDUF in a larger project, and exercising more control over “what” get’s done. You wouldn’t want 400+ developers running around “exploring ideas”, then finding yourself with modules and components that don’t fit together.
So, for increasing project size, I would think that BIGDUF becomes more useful. I consent that “essential” is probably not the best word to use :-). “Useful” might be more appropriate.