Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.
The design activities referred to includes the whole range of styles, from the classic up-front design to the emergent design style commonly found in agile projects.
Peoples beliefs differ about to which extent good design matters, but Martin has run into a rather extreme opinion a few times:
Indeed I’ve come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.
The reason that trading design effort for development speed won’t work for most projects is that the system rapidly becomes hard to work with, and the time saved on design activities are soon lost due to decreased productivity.
The trick is to figure out where the design payoff line will be for your particular system before dropping any design activities, but we can only rely on experience and gut feeling to figure it out, since we can’t measure software development productivity.
However, experience is needed to make a good estimation of where the design payoff line will be in a given situation, and Antti Tarvainen pointed out that the lack of experience not only is troublesome when a software development novice has to make the judgement call - it also makes it hard for managers to estimate the economic value of design efforts:
Our software development novice cannot make the judgement about the value of design, because his conceptual model is not rich enough...The problem is, he doesn't know of how much design is worth compared with just writing features without design. Undervaluing design leads to bad code quality and keeping to code-and-fix. Overvaluing it leads to analysis paralysis (in big design up front) or just low velocity (in agile methodologies).
Dennis E. Hamilton (a.k.a Orchid) accredited a couple of common mistakes to making the call without having the required design maturity:
This explains common novice blunders: having an appetite beyond our capability and our stamina. I’ve got the tiger by the tail, now how do I get it into the frying pan? I could have saved my ass by envisioning the endgame first, but I don’t know that, do I? I will be operating somewhere out in the no design region where I don’t deliver any functionality whatsoever. I suppose that has to be somewhere on the imaginary plane above Fowler’s safe-landing territory
This also explains some common management blunders: taking out crushing technical debt without recognizing it and then having no means to ever repay it. Management probably needs to understand software lifecycles and risk management far more than the cybersmiths, even without the skill (and certainly no foolish inclination) to do the work themselves.
Fowler concluded his article by sharing his view of where the design payoff line is:
I take the view that it’s much lower than most people think: usually weeks not months. But again this can only be a judgment call.
If that view is correct, almost all software systems would suffer from doing design trade-offs.
/filters:no_upscale()/sponsorship/topic/c7a3c369-fdfd-4c13-b1f1-4938dc3bedc5/KalixLightbendLogoRSB2023-1681370636831.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/articles/twitter-staging-environment/en/smallimage/logo-1675028662311.jpg){kind=logo}
/articles/metrics-quality-software/en/smallimage/finding-adequate-metrics-for-process-quality-in-software-development-small-1673953064694.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/articles/architecture-modernization-domain-driven-discovery/en/smallimage/start-your-architecture-modernization-with-domain-driven-discovery-small-1683106490819.jpg)
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/architecture-trends-2023/en/smallimage/the-infoq-trends-report-1680611416202.jpeg)
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
/articles/istio-ambient-mesh/en/smallimage/logo-1678364642232.jpg){kind=logo}
/articles/effective-architecture-conversations/en/smallimage/have-effective-conversations-with-business-stakeholders-about-software-architecture-small-1677231728391.jpg)
/articles/creating-decentralized-apps/en/smallimage/LOGO-1676916574942.jpg){kind=logo}
/presentations/data-streams-architecture/en/smallimage/Kai_Waehner-s-1675025271514.jpg)
/articles/architecture-skeptics-guide/en/smallimage/a-skeptics-guide-to-software-architecture-decisions-small-1672223516348.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
Community comments
Ah, Alfresco
by Steven Devijver,
Fowler's article
by Mike Mormando,
+ ------------ ------------ -
by Remember Objective,
Design is planning
by Peter Ritchie,
Re: Design is planning
by Mittal Bhiogade,
Re: Design is planning
by Yagiz Erkan,
Re: Design is planning
by Shane Duan,
Re: Design is planning
by Yagiz Erkan,
Re: Design is planning
by Wayne Mack,
Re: Design is planning
by Yagiz Erkan,
Re: Design is planning
by Wayne Mack,
Time allocated for design should depend on the useful life of the software
by Sai Matam,
Ah, Alfresco
by Steven Devijver,
Your message is awaiting moderation. Thank you for participating in the discussion.
Meaning that you have to know up front the depth and scale of pretty much all of the issues you will be confronted with. Alfresco ...
Which reminds me of a thing: isn't there a difference between a design issue and a design opportunity? And aren't such opportunities present throughout the duration of any project?
Fowler's article
by Mike Mormando,
Your message is awaiting moderation. Thank you for participating in the discussion.
I read Mr. Fowler's article, and in it he readily admits that all his terms and figures were made up in order to support his argument about the way things should work in his opinion. Not exactly the sort of thing we should be basing our industry practices on...in my opinion anyway.
+ ------------ ------------ -
by Remember Objective,
Your message is awaiting moderation. Thank you for participating in the discussion.
The subject line depicts a sparkplug conceptually.
Add a few boxes and dotted lines and this is what passes for design in software.
This is a design:
diagram:
www.championsparkplugs.com/images/pic_plug411.jpg
text:
www.championsparkplugs.com/more_info.asp?otherM...
Any questions?
Of course there is design in software--it must be a solution to an amalgamation of different problems, including customer fit.
Analysis is essential and only badly done analysis activities result in analysis paralysis--when the actual problem has not been contacted. Too much analysis as such doesn't result in analysis paralysis because it yields concepts. Not lofty disconnected concepts, but concepts grounded in the real problems you're trying to solve.
Design is planning
by Peter Ritchie,
Your message is awaiting moderation. Thank you for participating in the discussion.
Design is planning. Without a plan you can neither tell the progress of the implementation nor the amount of effort left.
With a team of seasoned designers and architects you can get by with less design; but I've never worked on a project that had no formal design at the beginning of development that completed on time or without a fair share of defects.
Re: Design is planning
by Mittal Bhiogade,
Your message is awaiting moderation. Thank you for participating in the discussion.
How is design success or failure measured ?
Re: Design is planning
by Yagiz Erkan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Maybe with the amount of major refactoring required during the development...
- Yagiz -
blog.decaresystems.ie
Re: Design is planning
by Shane Duan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sorry but this seems to indicate that major refactoring is a bad thing. As you gain deeper insight of your domain and your application, some kind of system-level refactoring is inevitable.
Re: Design is planning
by Yagiz Erkan,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'm not saying that it's a bad thing, on the contrary, it has to be done but the reason behind refactoring is to improve the design. If the design needs improvement, it means that there was a better way of doing things when we though about them previously.
I'm not sure if it's a good thing to try to qualify an activity "major refactoring", however, ideally, in a perfect world, we shouldn't do refactorings because in such a world of fantasy, all the pieces would fit together perfectly. This never happens so we refactor in order to come close to it. Therefore, my logic says that if the design could be close to perfection, it wouldn't need major refactorings... ;)
- Yagiz -
blog.decaresystems.ie
Re: Design is planning
by Wayne Mack,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think a different view of design is that multiple alternatives are possible and it is highly subjective as to which may be better. The added difficulty is that without understanding all of the details it is impossible to predict which approach better handles the details. Refactoring is not a failure, it is merely an admission that we proceeded with the knowledge available at the time and discovered more information as we proceeded.
The difference in approaches between planning (design before coding) and refactoring (design after coding) is the mechanism we use to try and discover uderlying details - using a non-functional paper model or using operational code. The trial and error aspect is still there, but the operational code ensures details are discovered and that extraneous suppositions are not included. The cost trade off is between doing the development twice for everything - first as a paper model and then as actual code - and doing the actual code and refactor as necessary.
Re: Design is planning
by Yagiz Erkan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Yes, it doesn't have to be or I'd rather say "it doesn't have to indicate a failure". Something good can be improved and made better. So I understand that the pre-refactoring state doesn't have to be "bad". But if we take the time and effort to refactor, this means we believe that the end result is going to be better than the original one...
I totally agree. But the point I'm trying to make is that if we had the perfect design in the beginning then we wouldn't discover more information along the way. So if we don't discover a huge amount of info as we proceed, I assume that our upfront design was close to the hypothetical perfect design.
On the other hand, I appreciate that there are more than one ways of designing a system...
- Yagiz -
Re: Design is planning
by Wayne Mack,
Your message is awaiting moderation. Thank you for participating in the discussion.
The problem, however, is that at the beginning we do not have a design. There is a required effort to discover information, leaving the true question to be "What is the most efficient method of discovering information and transforming it into a solution?"
On a paper design effort, "refactoring" is common and accepted, yet some then indicate that it is some how a failure to apply this approach directly to code rather than paper models. The approach really boils down to deciding whether to try and achieve perfection (or at least acceptability) in a paper design and then implement code from the paper design, or begin working with code and use that as the medium to achieve acceptability.
Time allocated for design should depend on the useful life of the software
by Sai Matam,
Your message is awaiting moderation. Thank you for participating in the discussion.
Martin Fowler agrees that it is 'hard to measure productivity'
and it is hard to assess the 'quality of design.' Fred Brooks
mentioned that there is a vast difference in programmer productivity.
We can assume the same with design.
Some teams may do a through design which would then be useful
as opposed to other teams who only go through the motions
of designing or teams that produce inadequate designs. Some
teams may place excessive importance to design representation.
They may spend lot of time in generating UML diagrams as
opposed to actual designing.
So inspite of all the above variables, a software project
manager should assign adequate amount of time to design based
on the expected life time of the software product/project
itself. Are you designing a sky scraper or do you need a
shack by the beach to be used for a day? Would it be useful
to spend two days designing a beach shack that you expect
to use for a day?
-- Sai Matam
www.CodeWalk.com