On 7/7/11 10:05 AM, Chet Hendrickson wrote:
> Hello software craftilizers,
>
> I just started following Ralf and Ron's discussion on this list and many
> things have popped in to my head. The one I would like to explore was
> triggered by the suggestion that something was not a design choice but
> an implementation detail.
>
> This seems to me to be the crux of software craftsmanship.
>
> Everything we put into or leave out of our code is a design choice. And,
> we must act and judge ourselves accordingly.
I think so. Whether we call it architecture (because we're looking at
big chunks of the overall picture) or implementation (because we're
looking at lines of code), it's all design.
It's tempting to think that we can start with the big picture and
decompose to implementation and be done. In fact, we generally find
details at the lower level that inform what we might do/have done
differently at a higher level. To the extent that our design tools
inhibit making those changes, they hurt us. To the extent that they
don't keep up with such changes made in the code, they become irrelevant
and misleading.
When I used dataflow diagrams, I did so because, even on a one-man
project, they helped me quickly get an idea of how I wanted to structure
the code. I did not use the accompanying data dictionary of structured
design, because my C code said that as clearly as the external document.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
It's tempting to think that we can start with the big picture and
decompose to implementation and be done. In fact, we generally find
details at the lower level that inform what we might do/have done
differently at a higher level. To the extent that our design tools
inhibit making those changes, they hurt us. To the extent that they
don't keep up with such changes made in the code, they become irrelevant
and misleading.
When I used dataflow diagrams, I did so because, even on a one-man
project, they helped me quickly get an idea of how I wanted to structure
the code. I did not use the accompanying data dictionary of structured
design, because my C code said that as clearly as the external document.
> 1. Is distributing code across two processes a design choice?
> 2. Is choosing REST vs SOAP a design choice?
> 3. Is hosting a component in a windows service vs IIS vs a console
> client a design choice?
> 4. Is "doing it the CQRS way" a design choice?
> 5. Is having a Frame class in a bowling gama kata solution a design
> choice?
> 6. Is putting an IsStrike() method on the Frame class a design choice?
> 7. Is holding rolls in a Frame class in an array (vs a list) a design
> choice?
> 8. Is refactoring to a strategy pattern a design choice?
Do you answer "no" for some of these? If so, I would be interested
in why, and ...
> I suggest, that not all questions should be answer with "yes".
> Otherwise we�d be code designers ;-) But we�re not. Sometimes we
> design, sometimes we implement (and that�s where implementation
> details creep in).
Why do you not think we are not code designers? What bad or good
things would happen if we were code designers?
What do you see as the distinction between implementing and
designing? What would happen, good or bad, if that distinction were
blurred or removed?
Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad
> What is "to design" (in software dev) vs "the design"?
> One is an activity, the other is a result of this activity.
> Wikipedia say this: http://en.wikipedia.org/wiki/Software_design
> "Software design is a process of problem solving and planning for a
> software solution. After the purpose and specifications of software
> are determined, software developers will design or employ designers to
> develop a plan for a solution. It includes low-level component and
> algorithm implementation issues as well as the architectural view."
> This at least seems to distinguish between desiging and something
> following design. Designing is a phase in software dev. (No, we should
> not start talking about BDUF here or waterfall. Such a phase could be
> as short as 5 minutes, I�d say. Let�s focus on the difference between
> designing and whatever else there is.)
There is no sharp line of difference. There is no moment when design
is over, because the design is influenced, often strongly, by the
changes we make in the program text.
As we have seen in the bowling example, the implementation can be
better or worse in terms of whatever measure we might use, depending
on changes made in the text.
Some potential measures of "design" quality might include
efficiency, coupling, cohesion, duplication, maintainability,
security, ... a very long list. Every single one of these is
expressed in the text of the program, and every single one of them
can be enhanced or impaired by changes in the text.
Changes made in the text can increase or decrease cohesion or
coupling. They can increase or decrease duplication, resulting in
more difficult maintenance, or less difficult.
> So is there a special time for designing? Is there a special scope for
> designing?
Yes. From the beginning of the project to the end, we need to be
attentive to design. From the top of the product, its UI or its
overall shape, to the bottom, the details of its smallest little
algorithm, we need to be attentive to design.
Design does not begin at some point in time or some level of the
program and then stop and some other point or level. Design goes on
all the time.
> If yes, when is this time and what�s its scope?
> If no, why should we use the term "to design" at all instead of just
> say "to program" or "to code"?
I will pretend this was not a rhetorical question.
We might use various terms to emphasize various aspects of what we
are doing, or various kinds of thoughts we are having. I would
personally tend not to say "I'm coding" because to me that connotes
a more or less mindless translation of some fixed idea into program
statements.
When I am writing a program, using TDD, my thoughts move more or
less freely from matters of detail, like how to write a for loop in
this language, to matters of design, like which object should
contain this particular operation, or what the operation should be
called, or what its parameters are.
In any given second, perhaps I'm doing only one thing, designing or
not designing. In any given ten minute period, I do many things,
many of which are design.
Ron Jeffries
www.XProgramming.com
The opinions expressed here /are/ necessarily those of XProgramming.com.
But I might change my mind.
Hello, Ralf. On Saturday, July 9, 2011, at 3:59:50 AM, you wrote:
> What is "to design" (in software dev) vs "the design"?
> One is an activity, the other is a result of this activity.
> Wikipedia say this: http://en.wikipedia.org/wiki/Software_design
> "Software design is a process of problem solving and planning for a
> software solution. After the purpose and specifications of software
> are determined, software developers will design or employ designers to
> develop a plan for a solution. It includes low-level component and
> algorithm implementation issues as well as the architectural view."
> This at least seems to distinguish between desiging and something
> following design. Designing is a phase in software dev. (No, we should
> not start talking about BDUF here or waterfall. Such a phase could be
> as short as 5 minutes, I悲 say. Let愀 focus on the difference between
> designing and whatever else there is.)There is no sharp line of difference. There is no moment when design
is over, because the design is influenced, often strongly, by the
changes we make in the program text.
As we have seen in the bowling example, the implementation can be
better or worse in terms of whatever measure we might use, depending
on changes made in the text.
Some potential measures of "design" quality might include
efficiency, coupling, cohesion, duplication, maintainability,
security, ... a very long list. Every single one of these is
expressed in the text of the program, and every single one of them
can be enhanced or impaired by changes in the text.
Changes made in the text can increase or decrease cohesion or
coupling. They can increase or decrease duplication, resulting in
more difficult maintenance, or less difficult.
Yes. From the beginning of the project to the end, we need to be
> So is there a special time for designing? Is there a special scope for
> designing?
attentive to design. From the top of the product, its UI or its
overall shape, to the bottom, the details of its smallest little
algorithm, we need to be attentive to design.
Design does not begin at some point in time or some level of the
program and then stop and some other point or level. Design goes on
all the time.
> If yes, when is this time and what愀 its scope?
> If no, why should we use the term "to design" at all instead of justI will pretend this was not a rhetorical question.
> say "to program" or "to code"?
We might use various terms to emphasize various aspects of what we
are doing, or various kinds of thoughts we are having. I would
personally tend not to say "I'm coding" because to me that connotes
a more or less mindless translation of some fixed idea into program
statements.
When I am writing a program, using TDD, my thoughts move more or
less freely from matters of detail, like how to write a for loop in
this language, to matters of design, like which object should
contain this particular operation, or what the operation should be
called, or what its parameters are.
In any given second, perhaps I'm doing only one thing, designing or
not designing. In any given ten minute period, I do many things,
many of which are design.
The opinions expressed here /are/ necessarily those of XProgramming.com.
But I might change my mind.
--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
> The real benefit to blur the lines between this is to have all of the team
> members thinking about the design rather than one "special" person and a
> culture of churning. I've worked in environments where this is the case far
> too often.
Certainly *a* very real benefit. :)
Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct answer?
> The real benefit to blur the lines between this is to have all of the team members thinking about the design rather than one "special" person and a culture of churning.
Sadly, one of the effects I've seen most often in Agile teams is the reduction if not outright elimination of design as an activity other than design-at-the-keyboard.
Sometimes I think that design, like documentation, is something which so many programmers loath that they welcome any excuse to avoid it.
One pathological example I encountered recently was some very negative comments on a 360 review was someone being labelled as "indecisive and insecure" because they "seemed to need to get other people's permission rather than just picking a direction and implementing a 'spike solution'". (This was in a team where failure to discuss designs had already been identified by two previous team members as a deep problem.)
In my darker moments, I have wondered if people who actively avoid design are indeed insecure themselves - producing working code proves you know what you're doing. It's a lot easier than having to defend a design or think up more than one way to solve a problem.
> On 9 Jul., 15:18, Ron Jeffries <ronjeffr...@acm.org> wrote:
>> There is no sharp line of difference. There is no moment when design
>> is over, because the design is influenced, often strongly, by the
>> changes we make in the program text.
>
> Do I understand correctly, you mean, design is always, at any time
> during software development? There is no time where you do only design and there is time where you
> only code. Both activities - designing and coding - almost always happen at the
> same time?
I sometimes design without coding. I may well chat with a business user about requirements and start to sketch out a possible domain model on a whiteboard. I'll also look at a set of requirements and often make some high level architectural design decisions (what programming language, whether a framework or persistence store is going to be needed soon, which ones and how that affects my production infrastructure requirements) so I think design without coding is not that unusual (although it can be an anti-pattern if you do too much of it),
As for coding without design, while I am sure you might be able to come up with a specific change that doesn't involve design (say fixing an off by one error, pretty much everything else involves design. For me design encompasses variable naming, method naming, the kinds of conditional operations (in ruby, if or unless the opposite), how to interact with a collection, which of the vairous array methods will most clearly express my intent with an operation, etc. To me, all of these are design activities - perhaps equivalent to picking the soft furnishings for an apartment. Of course, there are also larger scale design activities (picking a language, deciding on a RESTful architecture) some of which are done separate from coding and some of which evolve naturally from making the next cucumber or rspec scenario/specification pass.
I think it's pretty common for the definition of design in software to include all of these items. For me, I think it is also *valuable* to say that all of these activities are part of design. If you don't, you can have the misunderstanding that it is OK to just "have a smart architect design the system and then throw it over the wall for a dumb coder to type it up". The fact that we *are* always designing is why those kinds of projects usually get into trouble. I think making it clear that we're always designing makes it more obvious that the quality of the system will be dependent on those many little design decisions that we make when we code (and anyone who has seen code written badly within a good design can attest to the fact that the coding process has a substantial impact on the quality of a code base.
Best Wishes,
Peter
> On 9 Jul., 15:18, Ron Jeffries <ronjeffr...@acm.org> wrote:
>> There is no sharp line of difference. There is no moment when design
>> is over, because the design is influenced, often strongly, by the
>> changes we make in the program text.
> Do I understand correctly, you mean, design is always, at any time
> during software development?
> There is no time where you do only design and there is time where you
> only code.
> Both activities - designing and coding - almost always happen at the
> same time?
> This then was your answer regarding when is design time.
There is time when I only design: any thinking about the program and
how it should work, while not at the computer, must be "do only
design".
I do not believe there should be a time when one does "only code".
That seems kind of mindless to me and I don't favor working
mindlessly.
>>
>> Design does not begin at some point in time or some level of the
>> program and then stop and some other point or level. Design goes on
>> all the time.
> Do I understand correctly you�re saying, design activities cover all
> levels of abstraction from a 30,000 feet view of a software system to
> the statements in a method?
Design is involved at all those times, yes. Design is going on at
almost every moment ... the way I do it. Others might somehow be
able to "code" without thinking about "design". I don't understand
how to partition my mind that way, nor why I would do it if I could.
>> When I am writing a program, using TDD, my thoughts move more or
>> less freely from matters of detail, like how to write a for loop in
>> this language, to matters of design, like which object should
>> contain this particular operation, or what the operation should be
>> called, or what its parameters are.
> Ah, here you�re distinguishing "matters of detail" and design.
Yes. Getting the right syntax down for something I want to say is
not design. It takes a few moments to write some code ... then
design thoughts come back in.
>>
>> In any given second, perhaps I'm doing only one thing, designing or
>> not designing. In any given ten minute period, I do many things,
>> many of which are design.
> So what is the result of your "minutes of design" during development?
> Although design and other activities are intermingled in your work you
> seem to have criteria to distinguish between design and other
> activities. So you must be able to name activities/artifacts belonging
> to design, and other activities/artifacts belonging to sth different.
Not really. I don't think there is a hard line, this is design, this
is not. There is a soft line: this is mostly about design, this is
mostly not.
> Please note: This is not a question about time anymore, but just about
> content. What belongs to design, what not? Can you point at something
> in your code and say, "See, this is here because it�s a matter of
> design."? You sure have criteria with which you can judge any decision
> during software development to belong either to the realm of design or
> not. What are those criteria? What are typical design questions/
> decisions? What are typical non-design questions/decisions?
Any time we can ask and answer the question "why is this here", it
should be a matter of design. The placement of things is surely an
essential design activity and if the placement of things is not
designed, what is it? Random? That seems bad.
Here are some examples ...
Non-design: "How do you write a for loop in this language? What is
the syntax of an if statement? What is the name of the function that
calculates square root?"
Design: "What test shall I write next? What object should contain
this functionality? What algorithm shall I use for summing up all
the frame scores? What would be a good name for this variable?"
Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve. --ELO
+1. I will possibly comment further below ...
On Sunday, July 10, 2011, at 11:36:12 AM, you wrote:
> I sometimes design without coding. I may well chat with a
> business user about requirements and start to sketch out a
> possible domain model on a whiteboard. I'll also look at a set of
> requirements and often make some high level architectural design
> decisions (what programming language, whether a framework or
> persistence store is going to be needed soon, which ones and how
> that affects my production infrastructure requirements) so I think
> design without coding is not that unusual (although it can be an
> anti-pattern if you do too much of it),
Yes. In Extreme Programming Installed, we refer to a Quick Design
Session where we sketch out what we are going to do. A team or pair
would use whatever notation they find useful, and I would think that
the more notations they know the better it would be. If they know
the same ones. :)
> As for coding without design, while I am sure you might be able to
> come up with a specific change that doesn't involve design (say
> fixing an off by one error, pretty much everything else involves
> design. For me design encompasses variable naming, method naming,
> the kinds of conditional operations (in ruby, if or unless the
> opposite), how to interact with a collection, which of the vairous
> array methods will most clearly express my intent with an
> operation, etc. To me, all of these are design activities -
> perhaps equivalent to picking the soft furnishings for an
> apartment. Of course, there are also larger scale design
> activities (picking a language, deciding on a RESTful
> architecture) some of which are done separate from coding and some
> of which evolve naturally from making the next cucumber or rspec
> scenario/specification pass.
Yes. I think one could argue that selecting the language is often
not design, since it is often picked by someone with no glimmer of
what we'll be doing with it. But it certainly influences the design,
sometimes strongly. For example, if I were into a flow-oriented
approach, I would be inclined to pick a language that expressed flow
nicely.
> I think it's pretty common for the definition of design in
> software to include all of these items. For me, I think it is also
> *valuable* to say that all of these activities are part of design.
> If you don't, you can have the misunderstanding that it is OK to
> just "have a smart architect design the system and then throw it
> over the wall for a dumb coder to type it up".
Exactly. It also means that there is little value to thinking it
might be OK to be good at "design" and not so good at "coding", but
that coding isn't important anyway.
> The fact that we
> *are* always designing is why those kinds of projects usually get
> into trouble. I think making it clear that we're always designing
> makes it more obvious that the quality of the system will be
> dependent on those many little design decisions that we make when
> we code (and anyone who has seen code written badly within a good
> design can attest to the fact that the coding process has a
> substantial impact on the quality of a code base.
Exactly.
Ron Jeffries
www.XProgramming.com
There is no art without intention. -- Duke Ellington
> So do you mean, any decision while developing software belongs to the
> realm of design?
To me, yes.
> Are then all decisions the same, equally important, of identical
> impact, on the same level?
No. Design decisions have different "event horizons". If I pick a bad name for a private variable within a method, renaming it won't be very hard or expensive to do. If I decide to use Scala for a project and later determine that node.js would have been a better fit, the cost of that change will be much greater.
> Or can we discern different levels/kinds of design, e.g. architectural
> design vs. some other design?
There is definitely a gradation of importance of design decisions based primarily on the impact to the project of having to change them later. It's why some decisions warrant a spike or even a full on due diligence on multiple possible implementations, whereas others are better to be made as well as possible in a few minutes and can always be easily changed as our understanding of the domain evolves.
But the much bigger question is why we would choose to try to distinguish specific levels of design. I can ruin a project with 10,000 small bad variable and method naming decisions as surely as I can by picking the wrong language (I work in an environment where I often get to pick my entire tech stack - language and all), framework, or class of data store. And it isn't just the naming, It's the precision with which we wield the scalpel that we use to dissect the problem domain into meaningful concepts. It's the way that we sunder large, messy domain concepts into elegant, thoughtful, malleable abstractions on a daily basis when coding that distinguishes good design, software, developers and projects from bad ones.
So perhaps my question back to your would be if we could make meaningful distinctions between different levels of design based upon some definition of importance (such as the cost of change, the risk to the project, etc), what would we do with that capability? Let's say that we came up with a thoughtful, detailed, well reasoned scale which allowed us to assign every design decision from the most trivial to the most earth shattering on a scale of 1 to 5. What would that allow us to do? What benefit would we get from formalizing that endeavor?
To be fair, I do think there is value in considering the implications of every design decision - if only fleetingly and subconsciously in the case of very small ones. I'm continually considering my design and will often ask myself "how much does this matter"? One of the things I love about TDD is that you're usually focused on small decisions, test coverage means that most of them are revocable, so you don't have to waste too much time in trying to foretell the future and figure out exactly what the software will or won't have to do. However, sometimes you do need to make those bigger decisions and it's quite valid (at least to me) to invest more time in them commensurate with the greater potential cost of having to revert them later. So I think most designers/architects/coders do have a sense of how costly a given decision is likely to be to change and will give more focus to decisions that will be harder to change, but I'm not sure about the benefit of trying to cleave the world of coding into arbitrary strata such as "architecture" vs "programming". After all, the only thing worse than programmers who don't design is architects who don't regularly code :)
Best Wishes,
Peter
It's not clear to whom the below is addressed. I'll answer for
myself and for what I've heard others say in this thread.
On Monday, July 11, 2011, at 12:03:57 AM, you wrote:
> So do you mean, any decision while developing software belongs to the
> realm of design?
No, but very many do. Some decisions may not be design decisions:
many, perhaps most, seem to be.
> While execution of decisions does not?
I'm not clear what "execution of decisions" means. I don't enter
some state where I'm not making decisions, even when typing. In the
previous sentence, I revised right in the middle to better make my
point.
Because many, perhaps most decisions are design related, it seems
more that I am making design decisions, large and small, all the
time, while doing other things like typing.
> Are then all decisions the same, equally important, of identical
> impact, on the same level?
No, not all decisions are equally important. I note in passing that
no one has suggested that they are.
Different decisions clearly have different impact, just as any two
lines of code, containing a mistake, generally produce two different
incorrect behaviors.
> Or can we discern different levels/kinds of design, e.g. architectural
> design vs. some other design?
Much has been written about levels of design. I believe that much of
it has the effect of dissecting the frog. We know more about frogs,
but the frog dies.
In actually designing a real program, we have the ability to see the
impact of some "high level" thing like architecture at some low
level in the code.
If the team and the individuals making up the team are not
"responsible" for the design, they can only push ahead, living with
difficulties, or "go around" them.
If the team is responsible for difficulties, then the extent to
which the design can be improved is limited almost exclusively by
their skill in what we could broadly call "refactoring".
Sometimes we can notice a mismatch between the design we have and
the design we need, and fix it directly in the code. Sometimes we
pull our heads up a bit, draw some pictures, have some discussion,
and then begin to push the code-cum-design in a new direction.
Sometimes we're just stuck with the inadequate design.
I think the Software Craftsmanship movement, and this list, is about
how to do this well, namely how to keep the code-cum-design always
as good as possible even though we can't know, in early days, just
what the impact of design decisions might be.
In essence, we don't make design decisions, if a decision is a thing
that, once decided, stays decided. We make design sketches, whether
on paper or in code, and refine those sketches continually as the
project goes on.
Ron Jeffries
www.XProgramming.com
Ron gave me a good suggestion once. -- Carlton (banshee858)
hah! wrong! :-)
I'm not so interested in the "what is and isn't design debate" but in
why it seems so important to you. I'm jumping wildly to conclusions
here, but I feel I'm detecting some trust issues either with your
current team or with team members you've worked with. That you don't
trust certain 'coders' to do design, so you are seeking some
definition of non-design work you can safely assign to them.
I went through this early in my career. I was the one not trusted, so
all my design decisions were double checked and challenged.
Unfortunately, that greatly slowed my own development in design.
Perhaps that explains why XP struck such a resonating chord with me. I
was free to work on a team of varying skills, learning design from the
designers, but also contributing to the design as well.
I also, again jumping wildly to conclusions, detect that you prefer
the architect vs coder paradigm, where a privileged few design for
some period of time until the design is done, whenever that is, then
hand off the design to the coders who implement it. I would not wish
to work in that environment again, either as the architect or the
coder.
--
Curtis Cooley
curtis...@gmail.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
I tend to agree. I have a rather broad definition of design. To me,
design is the process of making decisions in the face of constraints,
so even as something as mundane as planning a birthday party is a
design problem.
The problem with the phrase 'implementation detail' is that it is sort
of dismissive, like the word 'only' or 'just'. Personally, I think
it's quite clear that the 'Broken Windows' theory of software us true,
and it points to the fact that many of the things that people want to
believe are 'just details' often can have significant effects over
time.
Michael Feathers - Chief Scientist, Obtiva
> hah! wrong! :-)
Excellent. Please tell us some ways that it is design. I'm sure
it'll lead to some interesting discussion.
Thanks,
Ron Jeffries
www.XProgramming.com
Show me the features!
if the different ways of doing it have different semantics or even
different feelings in the head of the programmer/reader/maintainer,
then i think that's into the realm of design. (and actually i'd argue
that even more "mundane" things like more or less whitespace in
non-whitespace-sensitive languages is design, just like how much white
space in a printed page is a form of design, but that is a different
thing than i was thinking of here.)
C++ ish examples to contemplate:
for( i = 0; i != 10; i++)
for( i = 0; i < 10; i++ )
for( i = 0; i < 10; ++i )
for( i = 0; i <= 9; ++i )
etc.
sincerely.
> As said earlier: if all�s design, then using the term is not very
> helpful. If there are no implementation details as opposed to design,
> then there does not seem much use in distingushing between "to
> implement" and "to design".
Yes. In software development, one of the best ways to do it is to
attend to design and implementation continuously and at the same
time.
> I don�t know about your job. But mine is to visit dozens of teams each
> year. And you can trust me [sic!] behind their difficulties from slow
> software to ugly brownfield code are just a few recurring root causes.
> One is constant misunderstandings.
Yes. One constant misunderstanding that leads to software rot is the
notion that the time for designing this thing, the time for
attending to its architecture, is over.
The time for architecture and design is now, always. These are
disparate skills from coding, but only in the same way that throwing
and catching are disparate skills in juggling.
Ron Jeffries
www.XProgramming.com
To be on the wire is life. The rest is waiting. --Karl Wallenda
Perhaps a better metaphor is offense/defense in basketball (or football in the rest of the world.) I can't tell you from the sidelines when you'll be doing each, but I can predict with confidence that you will start to lose the minute you ignore either one.
> Perhaps a better metaphor is offense/defense in basketball (or football in
> the rest of the world.) I can't tell you from the sidelines when you'll be
> doing each, but I can predict with confidence that you will start to lose
> the minute you ignore either one.
Yes.
Ron Jeffries
www.XProgramming.com
It is not he who reviles or strikes you who insults you,
but your opinion that these things are insulting. ~ Epictetus
> As said earlier: if all´s design, then using the term is not very
> helpful.
I disagree (see next statement)
> If there are no implementation details as opposed to design,
> then there does not seem much use in distingushing between "to
> implement" and "to design".
I agree :)
The value of using the term design ubiquitously is in making it clear that programming is a creative activity where skill is much more important than time or warm bodies. If I need a hole dug, I just need as many people with shovels as can fit around the hole running as fast and as long as they can. If I need a great song written, hiring 20 song writers straight out of college will probably be less valuable than hiring one master song writer. One of the biggest myths of software development is the fungible resource. Making it clear that the process is one of design rather than one of typing helps to put that myth to bed.
> There is another interesting term: architecture.
> What exactly is software architecture? Are there decisions which
> specifically belong to the realm of software architecture?
Probably, but I don't think it's a bright line and I don't think the distinction is terribly interesting. Lets say that we cataloged the full list of possible decisions and were able to distinguish design (or "architecture in the small") from architecture in the large. Given that both are crucial and demand our attention, focus and skill, what would we do that we don't already (we already probably don't ask new apprentices to select our persistence mechanisms, frameworks or design our core domain metaphors without a little adult supervision and we already know when it makes sense to invest a couple of hours discussing, spiking and playing with a metaphor that is likely to be at the heart of our domain.
> The child sure would then ask, "What is programming?" and you´d try to
> explain how computers can be instructued with bits and bytes to do
> stuff ;-)
I think these days that would be by far the least interesting definition of what we do - and for many business programmers, the least accurate. That is like saying that a song writer makes markings of musical notation onto a paper. It may be true, but it misses the true value (except for low level and system programming). Most business programmers are engaged in a discussion with business stakeholders to find out how best to craft an application to add business value while staying within engineering constraints relating to maintainability, performance and other non-functional requirements. The vast majority of our job is coming up with clear, elegant expressions of intent that can be executed to confirm correctness (tests/specs/scenarios) and elegant domain abstractions to allow those expressions of intent to pass. And the elegance isn't some kind of fancy "lipstick on a pig" or unnecessary adding of vanity pieces to the software - it is the very thing. To be able to concisely describe and implement the essence of the business requirements in a way that will keep the code simple, comprehensible and maintainable. We don't write software so much as we select and invent elegant metaphors for the elements of a real world system we want to model. We then happen to spend a few minutes encoding those in the syntax de jour, carefully choosing our tools as a good artist would pick between charcoals or watercolors, between a thinner brush or a thicker to use the tools of their trade effectively to best express their creative output.
> What would you reply to the drill down question, "What does designing
> software mean, Curtis? In school we programmed a computer to show
> pictures and let a robot run arround by putting together little puzzle
> pieces." (I´m alluding to the Scratch platform here.)
And we are in the business of figuring out what puzzle pieces should go where. Telling the computer what to do is the least interesting and challenging part of the endeavor - outside of specific programming domains such as some embedded or real time systems where it is truly more of an engineering challenge than a business design one. I'd say that there are business people who know they'd like puzzle pieces moved around because they want something built with the puzzle pieces. But what they want is vey, very complex and we work with the business people to figure out the best way to put all those little puzzle pieces together to give them the software that they need and to allow them to change their needs as we work with them without having to start from scratch because our instructions are too complex and confusing to read and maintain. I might even say that we work with them to figure out where they really want the puzzle pieces to go, because they know that they want a car made out of puzzle pieces, but by talking with them about their needs we help them to determine whether it should be an Escalade or a 2 seater classic sports car.
> And as long as there are people on a team who cannot define a much
> used term precisely I fear there´s trouble ahead.
I think there needs to be a shared understanding and culture. That does not always result in a formal, agreed glossary (although especially in the business domain I find it useful to create such a glossary, I'm still trying to determine what a formal definition of design would give us that we can't get from a shared cultural understanding (which I believe is important).
> I don´t know about your job. But mine is to visit dozens of teams each
> year. And you can trust me [sic!] behind their difficulties from slow
> software to ugly brownfield code are just a few recurring root causes.
> One is constant misunderstandings.
I agree, and one of those is the misunderstanding (especially within management) that software is not fundamentally a design activity.
Best Wishes,
Peter
my apologies for mis-interpreting your intention.
sincerely.
> On 12 Jul., 13:45, Ron Jeffries <ronjeffr...@acm.org> wrote:
>> The time for architecture and design is now, always. These are
>> disparate skills from coding, but only in the same way that throwing
>> and catching are disparate skills in juggling.
> Again let me ask what this "thing" architecture or design is in
> contrast to implementation or whatever.
I feel quite sure that you have read as many definitions as I have
and thought about them. So why not propose yours ...
and then please tell us what we're going to do differently given
that we have architecture, design, and whatever else all nicely
separated out.
> ... something about soccer (or football) ...
> You�re emphazising "total programming". I understood that.
> Still, though, it�s is not clear to me what exactly belongs to the
> different activities (or aspects) you�re then engaging in concurrently
> or in a masterful holistic manner.
I don't understand what you are trying to discover. In doing the
work, I don't classify the world as "this is architecture, this is
implementation", because I don't find it to be a useful
classification. If you do, I'd like to understand why.
Let me be the one to quote scripture for a bit. Today's reading is
from the book of Wikipedia, Chapter Software Architecture:
The software architecture discipline is centered on the idea of
reducing complexity through abstraction and separation of
concerns. To date there is still no agreement on the precise
definition of the term �software architecture�.
...
Architecture is design but not all design is architectural.[1] In
practice, the architect is the one who draws the line between
software architecture (architectural design) and detailed design
(non-architectural design). There aren't rules or guidelines that
fit all cases. Examples of rules or heuristics that architects (or
organizations) can establish when they want to distinguish between
architecture and detailed design include:
Architecture is driven by non-functional requirements, while
functional design is driven by functional requirements.
Pseudo-code belongs in the detailed design document.
UML component, deployment, and package diagrams generally appear
in software architecture documents; UML class, object, and
behavior diagrams appear in detailed functional design
documents.
The distinction between architecture, design, and implementation is
rooted historically in a separation between architect, designer, and
coder. These distinctions are not useful to me, and IMO mostly not
applicable to the topic of this list.
These distinctions are not useful to me because I am an adherent,
and arguably creator, of Agile methodology. As such, I believe in
cohesive cross-functional teams and individuals, rather than
dividing up projects and people into things like architects and
coders.
These distinctions are not, in my opinion, very applicable to this
list, because we are here to address all the skills and practices
that make up software, looking at it all from the viewpoint of
craftsmanship. Craftsmanship is rather an integrated view of doing
things, where things are typically created by a single individual,
working from top to bottom. (For some definition of top to bottom,
of course. Most of the best woodworkers do not grow their own
trees.)
> Please name a single question which to you belongs in the realm of
> software architecture.
Well, I really don't think there is a bright line and that any such
thing could be argued with. I'll see if I can ...
"Shall we build an object-oriented language compiler, or a
functional language compiler?"
But this might actually be product planning.
> Please name a single question which to you belongs in the realm of
> software design.
"Shall we keep this information in an array, or build a
specialized collection type for it?"
But with proper encapsulation, this might be an implementation
detail.
> Please name a single question which to you belongs in the realm of
> software implementation.
"Is it faster to do a = a + 1, or a++, or ++a?"
The thing is, all of these are just questions. I don't know what
value there is in classifying them. Can you tell us what value we
might find in doing so?
> I�m choosing these three terms because they keep appearing in software
> literature and education. So I guess it would be very helpful for all
> software development apprentices to get an answer from you as to what
> you consider to fall under these categories.
Why mine? I'm the guy who thinks these distinctions are dated and
generally not useful for any purposes I've had for decades. What are
your definitions ... and how do you propose we should apply them in
our lives, and in this craftsmanship list?
Ron Jeffries
www.XProgramming.com
Learning is a human process, and knowledge is not what is found in the library.
I guess the only distinction I make is which hat I'm wearing while
doing TDD. While writing tests and the code to get them to pass, I'm
wearing the developer hat. While refactoring, I'm wearing the
refactoring hat. When I was learning and mastering (actually I'm still
mastering) TDD, I was told that it's important to know which hat you
are wearing. Do not add functionality while wearing the refactoring
hat. Do not refactor while wearing the developer hat.
As I've become better at TDD, I find those not so much rules but
guidelines. When my comfort level is high, i.e. fear is low, I find
myself off refactoring something while a test is red. GASP. I know, I
know, but I'm comfortable with that and I know the risks.
I'm not sure there is a clear mapping from design vs implementation to
the hats. Or even if that is useful, but that is the closest thing I
can think of when considering architecture, design, and
implementation. Like Ron said, in the Agile and Craftsmanship worlds,
perhaps the distinction is archaic and not longer useful, since they
are just skills and tools we must all master on our journey.
Perhaps as an apprentice, or advanced beginner if we're talking
Dryfus, learning implementation, design and architecture distinctly
from the others is useful, but I would assert that to move to
journeyman, or novice/competent, one would need to learn to apply them
continuously and without consciously switching hats so to speak. But
as I read and edited this post and thought about it more, I lean more
towards perhaps not.
You must have very messy hair :-D
> So what youīŋŊre all saying seems to be:
and subsequently ...
> Is [this] about right?
> "Why should we structure our domain terminology? WhatīŋŊs the use for
> different terms like architecture, design, implementation?
This, on my part, was in fact a question to you. I would like to
hear your answer. What benefits do you (or any other reader here)
find in differentiating terms like those? How do they help you?
> In the end you should always do everything at the same time.
> Always be an architect (whatever that means), always be a designer
> (whatever that means), always be an implementor.
This is almost what I'd say. I would say that in producing an actual
program, we realize that we will discover mistakes that someone
might think of as being in architecture, design, implementation.
As such, if we are good enough to be able to correct for inevitable
mistakes at any level, at any time, our system will work better than
if we are not able to do that.
> Every developer should be able to decide every question at all times
> whenever it comes up.
It would be good if every developer were this capable. It is a thing
to strive for, despite the fact that most of us will never be that
capable in every area we may encounter.
> Any distinction between different aspects of software development in
> the end is contra productive. It bears the chance of falling back into
> an unholy separation of phases or division of labor.
The value of the distinctions between architecture, design,
implementation is not clear by the time we get down to
implementing. If, when we are implementing, we constrain ourselves
not to deal with problems at "higher levels", those problems will
likely not be dealt with at all. If we delegate those problems
upward, the people outside the team will not have the understanding
that we, the builders, have.
Therefore, it would be good if we could deal with issues when and
where they are encountered, using whatever techniques of thinking,
drawing, programming are most helpful, in the face of the
reality of implementation.
> Just be clear if youīŋŊre creating new stuff - or if youīŋŊre rearranging
> existing stuff. Rearranging should not break existing stuff. Get your
> tests to green, keep your tests green.
Yes, do this. There is no "just do this". This work is complex.
Trivializing our thoughts here will lead to misunderstanding. Has
led to, in fact.
> WeīŋŊre building the most complex systems. WeīŋŊre building them from most
> abstract materials. The systems are hardly tangible. Above all they
> are very volatile.
We do well to strive to keep our systems as simple as possible for
as long as possible. We do well to keep an eye on both the abstract
and the concrete. We do well to keep our work as tangible and
visible as possible. We do well to work to reduce volatility.
> ThatīŋŊs why we better not develop a precise terminology for what weīŋŊre
> doing; it would only distract from the necessity to keep everything in
> view; it would be futile in a world of constant change.
Precise terminology has advantages when it matches reality and
serves what we are doing. For me, the value of distinguishing
architecture, design, and such terms is not clear. Again, I ask for
you to tell us what practical (or other) value you see in them.
> Abstraction would divert from the most important aspect of software
> development: detail. ItīŋŊs always about detail, the most minute
> details. You get your indexes wrong, the program crashes; you go over
> a list once too often, the program becomes to slow.
Not at all! Abstraction is quite valuable. Abstraction is how we
recognize that the program is going over the list three times and
could be doing it once. Abstraction is the process whereby we create
general purpose functionality, be it a sorting function or a
compiler or an operating system. Abstraction is essential.
Abstraction on its own is fantasy.
Software development is never about any one thing. It is always
about everything. The most beautiful abstraction can be ruined by an
index that is wrong. The best code will not perform well nor be as
maintainable when built using poor abstractions. The ideas of
software work together.
> ThatīŋŊs why the best way to teach programming is by just doing it.
> Talking about detail is cheap. But actually sitting in front of source
> code/detail shows the real thing. The nuances of when to choose which
> of the many options cannot really be captured in rules.
I'm not sure what the best way to teach programming might be. It
happens a bunch of us were talking this week about someone with a
degree in computer science who, showing up to apply for a
programming job, was found not to be able to program at all. This
suggests that doing programming might be important to learning
programming.
I would expect that experiencing the results of one's
"architecture", whatever that is, would be a good way to learn to do
whatever it is, just as I wish that whatever designer figured out
that airplane seat in the back corner of the plane had had to ride
cross-country in it, along with the bean counter who demanded one
more seat. Add in a crying baby somewhere just to make sure that
these high-level thinkers really understand the impact of their
abstract decisions.
> It always depends... In the end itīŋŊs 'programming by the seats of
> your pants'. You either have feeling for it or you donīŋŊt. So there
> is no teaching but just learning.
Yes, there are dependencies everywhere. We saw that in the tiny
program you wrote to do bowling, where details in the code and tests
showed us concerns in the design that had gone before, just as the
design informed the code that followed.
People will have more feeling for things, or less. More is better.
It is quite possible that there is only learning, in the sense that
we cannot "teach" knowledge into a mind that is not engaged. The
question of how best to help a learner is far from resolved.
As one learner, I can report that I've immersed myself in all
aspects of this work for a half century, and that while distinctions
like architecture v design v implementation may have been useful in
separating out things to talk about, they have always been less
useful when it has come down to doing the work.
When I first started programming, I was a math major. There were
no computers in college then, except perhaps at places like MIT. I
got a summer job, and was told on the first day to "write a
subroutine calculating the great circle distance between two
points on the earth".
My mentor tried to help me. I recall my first sticking point in
programming: the statement A = A + 1. This is clearly impossible.
There is no value A such that A = A + 1.
There I was, faced with a half-dozen characters to be punched on a
card, staring right into the abyss of computer architecture and
programming language design. All there in those few characters.
What a great day, the first of over 18,000 days leading to today,
which looks like a great day as well, because I get to do this
interesting and challenging work.
> Master pilots need no special terminolgy to be experts. They just do
> it. Master craftsmen donīŋŊt need special terminology to be experts.
Actually every craft uses special terminology, and lots of it. So do
we. We even bandy about words like architecture and design, plus
many more.
> They just do it. So you better watch and learn and try for yourself."
There is no "just" in "do it". Doing it is bloody difficult, because
whenever we just barely manage to do whatever they asked of us last
time, they seem to ask for something more difficult the next time.
Often, perhaps always, we cannot be good at the more abstract
without being good at the more concrete, because we have to
understand the impact of the concrete on our abstract plans and
designs.
Once upon a time, I worked with two other people, another
programmer and a hardware engineer to determine why one computer
in the computer room was crashing running the same software that
others ran perfectly.
We worked together with a fair amount of heat, but fortunately
enough light. I had a decent understanding of what was going on in
the software, and what it used the hardware to do. The other
programmer knew the code of the system incredibly well. (He was
generally a genius. We all were. It was helpful, oddly enough.)
I kind of choreographed experiments, with the other two putting
software and hardware probes in. We scoped various parts of the
computer and wrote routines to exercise different parts of the
code. Finally we had things configured so that we could crash the
system at will. The hardware guy had his scope near where the
problem was occurring, near enough to finally diagnose the
problem, which turned out to be a "slow diode".
I still have no idea what a slow diode is. I do know that without
deep understanding of everything from top to bottom in that system
we would have never found the problem, though a shotgun approach
to card replacement might have "fixed" it.
Abstract and concrete interact. We do better if we understand and
can work at all levels, and we put together teams that can work at
all levels whenever we can.
> Is that about right?
Not really. It reads more like a sarcastic attempt to parody and
make a mockery of what we are saying. I welcome the opportunity to
convert the outline back to something that is more like what I
actually believe.
I still would like to have you describe your use of the terms, and
the value you find in thinking about them as you create actual
software. Could you do that for us please?
Ron Jeffries
www.XProgramming.com
Learn the principle, abide by the principle, and dissolve the principle.
-- Bruce Lee
On 15 Jul., 13:10, Ron Jeffries <ronjeffr...@acm.org> wrote:I can tell you why I think precise and rich language is good: It´s
> I still would like to have you describe your use of the terms, and
> the value you find in thinking about them as you create actual
> software. Could you do that for us please?
easier to talk about stuff with a differentiated language.
> You don�t share this view. That�s fine with me. Maybe there are
> several approaches to software development as there are many paths to
> enlightenment ;-) So let�s not fight over belief
Perhaps you could give an example of a communication where the
distinction between, say, "architecture" and "design" is important.
Please be sure to include definitions ...
Ron Jeffries
www.XProgramming.com
Reason is and ought only to be the slave of the passions. -- David Hume
> It�s interesting to see how you require me to provide definitions for
> sw architecture or design, just because I believe in precise language.
> That�s like requiring a kid asking questions to its parent to know the
> answers already.
Actually, as a parent, often the best thing to do is to ask the
child for its current understanding, so as to calibrate the answer.
In this case, however, you are not a child, you are a member of the
group, and it seems quite fair to ask you to contribute your ideas,
as well as ask questions and attempt to characterize other people's
thoughts.
> I thought this forum was about collaborative development of all sorts
> of aspects of the trade - and not fingerpointing. "You�re asking those
> questions, you need to have an answer." Why?
Well, since it is about collaborative development, I feel that it is
your turn to collaborate. Since you value these definitions, perhaps
you have some working definitions in your head. We'd like to hear
about them.
Ron Jeffries
www.XProgramming.com
For me, XP ain't out there, it's in here. -- Bill Caputo
Hello, Ralf. On Saturday, July 16, 2011, at 3:13:11 AM, you wrote:
> It愀 interesting to see how you require me to provide definitions for
> sw architecture or design, just because I believe in precise language.
> That愀 like requiring a kid asking questions to its parent to know the
> answers already.
Actually, as a parent, often the best thing to do is to ask the
child for its current understanding, so as to calibrate the answer.
In this case, however, you are not a child, you are a member of the
group, and it seems quite fair to ask you to contribute your ideas,
as well as ask questions and attempt to characterize other people's
thoughts.
> I thought this forum was about collaborative development of all sorts
> of aspects of the trade - and not fingerpointing. "You愉e asking those
> questions, you need to have an answer." Why?Well, since it is about collaborative development, I feel that it is
your turn to collaborate. Since you value these definitions, perhaps
you have some working definitions in your head. We'd like to hear
about them.
For me, XP ain't out there, it's in here. -- Bill Caputo
I am in fact actively interested in your views to the contrary and
would be actively interested in the reasons behind them. I am
actively interested in examples where tighter definitions of these
terms would be beneficial.
I am not, however, inclined at this time to work to form tighter
definitions, because I have not felt the need for them.
> To be honest: I had suspected this, but wanted to be sure.
I am not sure that the few active posters to this thread are
characteristic of the entire group. I am quite sure that if you are
interested in tightening up the definitions, expressing something
about your current working definitions, and giving some examples of
how they are helpful, would lead to some interesting discussion.
You would certainly have the opportunity to shape your ideas in a
fiery crucible, and at the same time, with people who do know rather
a lot about software development.
Of course it is up to you.
Ron Jeffries
www.XProgramming.com
Fatalism is born of the fear of failure, for we all believe that we carry
success in our own hands, and we suspect that our hands are weak. -- Conrad
It seems to me that you've been given some informal definitions, but
they didn't fit your ideas about these terms. It seems that you're
playing the game of "Bring me a rock. No, not that rock."
My definition of design is making a choice between reasonable
alternatives. My definition of architecture is designing buildings.
In software design, I think the word architecture is used to puff up
those who get to make bigger decisions without having to deal with the
code-level consequences of those decisions. Oh, to be sure, there are
exceptions to this. But in my experience, most of those who want to
take the title of "architect" don't want the responsibility of making
the systems work. They just want the credit. If things go badly, they
can always blame the programmers for fumbling the "mere implementation."
Your turn.
> To be honest: I had suspected this, but wanted to be sure.
By the way, that comment gives me the impression that you're not being
honest at all.
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
My definition of design is making a choice between reasonable alternatives. My definition of architecture is designing buildings.
He also uses the word programming without specifying it. I'm guessing he also has a definition for that.
As others have asked, I'm really interested given your focus with this to hear your first thoughts of an appropriate definition for terms like design and architecture. Please give us your thoughts - even if they are unfinished.
Best Wishes,
Peter
> On 17 Jul., 23:45, George Dinwiddie <li...@iDIAcomputing.com> wrote:
>> It seems to me that you've been given some informal definitions, but
>> they didn't fit your ideas about these terms. It seems that you're
>> playing the game of "Bring me a rock. No, not that rock."
>
> George, I´m not playing a game here. I´m just asking a very
> straightforward question: What´s the definition of the terms "software
> architecture" and "software design" of the sw craftsmanship movement?
Great question. What's *your* answer? You've clearly thought about the problem and I'd look forward to your working definition.
Best Wishes,
Peter
On 7/18/11 11:33 AM, Ralf Westphal wrote:
> On 17 Jul., 23:45, George Dinwiddie<li...@iDIAcomputing.com> wrote:
>> It seems to me that you've been given some informal definitions, but
>> they didn't fit your ideas about these terms. It seems that you're
>> playing the game of "Bring me a rock. No, not that rock."
>
> George, I´m not playing a game here. I´m just asking a very
> straightforward question: What´s the definition of the terms "software
> architecture" and "software design" of the sw craftsmanship movement?
Has it become clear to you that individual people may have assigned
meaning to these terms, but that there is no "movement" authority to
make an official definition.
> No definition has been given to me so far. So I haven´t refused any
> "rocks".
Perhaps it hasn't been phrased as a dictionary definition, but I've seen
people describe what they mean by software design. I've also seen that
it is important to you to distinguish between "architecture," "design,"
and "implementation." Yet I haven't seen you offer a definition of these
things, nor state what benefit you find in making such distinctions.
Perhaps I missed your statement of these things.
I cannot imagine why you want these definitions from people who don't
find much value in segregating them.
> Answers could be:
> a. "Definitions of those terms are none of the business of sw
> craftsmanship. SWC is orthogonal to these terms like Scrum is. So
> please stop asking us."
> b. "SWC is opposed to defining those terms. They do not make sense for
> SWC practitioners because of reasons A, B, C."
> c. "SWC defines the terms as follows: ..."
>
> I´d immediately stop asking if I received an answer along one of the
> above lines.
>
>>
>> My definition of design is making a choice between reasonable
>> alternatives. My definition of architecture is designing buildings.
>
> Thx for your definitions.
>
> So you mean the term design pertains to "Should we use an ORM or not?"
> as well as "Should we distribute the functionality across processes?"
> as well as "Should I use a for-loop or a while-loop?" as well as "Is a
> one letter variable name ok for the array index?" Each and any
> decision is a design decision to you, because, well, decisions are
> made between alternative options.
Yes, all of those are design decisions. Do you disagree?
> So you mean the term "software architecture" is meaningless, because,
> well, software developers are not in the construction business.
>
>>
>> In software design, I think the word architecture is used to puff up
>
> Or do you mean, "architecture" has a meaning for software developers?
> And architecture is a part of software design, because you say "in
> software design" (which subsumes architecture to be part of it).
> I´m confused. Either architecture is about buildings or it´s part of
> software design. Hm...
>
>
>> exceptions to this. But in my experience, most of those who want to
>> take the title of "architect" don't want the responsibility of making
>> the systems work. They just want the credit. If things go badly, they
>> can always blame the programmers for fumbling the "mere implementation."
>
> So you mean the term "architecture" should not be used because there
> are guys who use it to negotiate higher salaries?
> Should we then abondon the use of terms like "programming", because it
> is often associated with lower salaries?
> Should we in general use less differentiated vocabulary because words,
> which not all software developers understand, open the doors to salary
> inequalities? "See, boss, I know what a Monad is, I should get a pay
> raise." - is that what you want to avoid?
No to all of your leading questions. They do not represent my meaning.
I'm waiting for your definition of design and architecture. As I said,
it's your turn. These terms are apparently important to you, but not so
important as to share your own definitions and how those definitions are
helpful to the process of creating software.
I can align myself with, respect, and learn from a person or movement
and still not agree with everything that person or movement says. I do
not agree with the assertion made above that the kinds of decisions
programmers make everyday are not design decisions. I really don't
have a definition of design, I have an understanding about what it is
and what it means. Well designed software is more pleasant to work on.
Building software using TDD, removing duplication, and having
awareness of SOLID and code smells, lead to software that is more
pleasant to work on. I don't think having a solid line separating
design from implementation details affects how pleasant software is to
work on.
I'm trying to think of a time where a misunderstanding about the exact
definition of design caused problems on a project. I can't really
think of one. Honestly, I've never been in a pairing session or any
other development activity and had someone say, "Oh, that's not
actually design." Even if they did, I'm pretty sure my response would
be, "how does that distinction change what we are doing?"
I think the reason we keep asking why the distinction between design
and implementation details is so important to you is because the
answer to that question influences the answer to the former question.
For example, if it's because you want to separate the two activities
and design for a while then implement for a while, then I guess Kent's
alluded to definition works. Design is what you do around a
whiteboard, and implementation is what you do once you load up the dev
environment. Decisions made at the keyboard are implementation
details. That only works for me if separating the activities is
important, which I believe not to be true.
I also assert that if it was paramount to have a precise definition of
design, an industry as old as ours would have one.
I also assert that this group does not have the sufficient circle of
influence to create one to satisfy the industry at large. I suppose we
could create one for us, but would that not create more communication
problems?
--
Curtis Cooley
curtis...@gmail.com
> I also assert that if it was paramount to have a precise definition of
> design, an industry as old as ours would have one.
Nicely said!
Dave Rooney
Agile Coach & Co-founder
Westboro Systems
http://www.westborosystems.com
One definition of architecture that I liked was "design decisions that
aren't easy to change later".
So in a craftsmanship and agile world, this definition is important
because now architecture is something we'd want to do less of?
> See how it�s happening again: one of the most venerated protagonists
> of the agile movement uses the term "design" - but what does it mean?
> He does not provide an explanation, because his book is not about
> design. But he sure has one, otherwise he could not tell whether it�s
> about design or not.
> And you - Curtis, Ron, Philip - want to tell me it�s not important to
> have a clear definition of the term "design"? Come on, guys, you can�t
> be serious. Or at least you can�t be in line with Kent Beck then.
We are serious. We all believe in "design", including Kent. We all
have an internal meaning for it. We are confident that we all mean
close enough to the same thing for effective communication and work.
We are happy to leave the word loosely defined, because we do not as
yet (i.e. after a half-century in my case) see much value in
tightening it up.
Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve. --ELO
>> The focus is on communication with people over working software. It's
>> not about walking them through a diagram of any sort. Software is
>> created by and for people and as humans we like to touch and play with
>> the things we make as this provides good feedback.
> That means what in terms of terminology? Craftsmen/artisans need less
> precise vocabulary because they engage in "show, don�t tell"
> activities? They wave hands instead of using specific terms?
I would be grateful for a little more courtesy, and a little less
mis-characterization of our meaning.
I believe, and I think a lot of us here believe, that the notion of
design is inherently fuzzy, that there is no bright line, and can be
no bright line.
I am getting that that belief distresses you. At the same time,
despite repeated requests, you have not set forth a candidate for
what the bright line should be, merely deplored that we do not have
one.
Have you got one? Please show it. If not, join us, because we don't
have one either.
Ron Jeffries
www.XProgramming.com
You have to either laugh or cry. -- Bill Rogers
> One definition of architecture that I liked was "design decisions that
> aren't easy to change later".
Yes ... and we'll do so well to find ways to reduce the number of
those, and defer them until the last responsible moment!
Ron Jeffries
www.XProgramming.com
The practices are not the knowing: they are a path to the knowing.
Ron Jeffries
www.XProgramming.com
Do only what is necessary. Keep only what you need.
--
I am late into this discussion, so my apologies if this has already been offered up, but this article by Jack Reeves (included in Uncle Bob's PPP book) is one if the best treatises on the question of design in software I have read. It is a number if years old now but I believe it still holds plenty insight.
http://www.developerdotstar.com/mag/articles/reeves_design.html
Kind regards,
Alan
> On 18 Jul., 22:31, Ron Jeffries <ronjeffr...@acm.org> wrote:
>> We are serious. We all believe in "design", including Kent. We all
>> have an internal meaning for it. We are confident that we all mean
>> close enough to the same thing for effective communication and work.
>> We are happy to leave the word loosely defined, because we do not as
>> yet (i.e. after a half-century in my case) see much value in
>> tightening it up.
> So when you go to a physician you�re content if he says, "Well, I�m
> always treating the whole person."?
> You don�t care if he can distinguish between anatomy and physiology?
I am tiring of these apparently sarcastic recastings of what people
say. You are creating straw man arguments that do not cast light on
the subject at hand. You are accusing us of not being able to
distinguish one thing from another when in fact we have gone beyond
simplistic attempts at bright lines to a more integrated view of
things.
> The science of medicine has come a long way in the past 200 years; and
> sometimes it has lost sight of the whole person, true. But in the end,
> I guess, we�re very, very happy for this "industry" to have lots of
> very specific and explicit definitions instead of people who are just
> confident to mean the same if they are using a certain term like maybe
> "physiology".
Anatomy is about structure, whatever that means, and physiology is
about process. Life is about an intimate combination of the two
which cannot be disentangled. We can take a frog apart to see how it
works, and if we do, it will die and we cannot put it back together
and make it work again.
Actually, if we were to talk to a competent physician, she would be
able to point out that when it comes to healing, there is no useful
bright line between subjects like anatomy and physiology, nor even
between physical and mental causes of disease and healing. The
better physician knows them all and moves freely among them all.
> What I�m trying to say is this: As long as there are no explicit
> definitions no falsification is possible. If TDD is claiming to
> improve the design of software and there is no definition for
> "design", then there is no way anybody can prove or disprove whether
> the claim is valid. The same is true for any other term like software
> architecture or implementation or performance etc.
On the contrary. TDD enables anyone who is competent with it to
improve the design of his or her program //by his or her own
standards//. It is a tool that can be used as part of building any
structure according to one's own definition of beauty.
TDD, refactoring, and so on, are [almost entirely] independent of
notions of design or architecture. They can be used to build any
software of essentially any design, of essentially any architecture.
> Somebody claims "With my method it�s easier/cheaper/faster to improve
> the design/architecture/implementation/performance...", then she
> better explains, what she means by
> design/architecture/implementation/
> performance and how to measure its value. Only then a comparison is
> possible between the status ante and the status post.
We claim that these tools enable us to make software better and to
do so more reliably.
Personally, I claim that if you will look at any program that you or
I write, and apply your own internal definitions of design and
architecture to explain to me what you do not like and what you do,
I can use TDD and refactoring to move the program in the direction
you prefer.
> But, well, if Ron is speaking for the whole group, then that�s fine
> with me. You�re content with the profession without precise
> definitions for central terms. Ok.
I speak for myself. I may occasionally try to summarize what I
understand of the writings of others. I do not "speak for" any
group. I even try not to speak too definitively for "Ron and Chet"
and he and I finish each others sentences.
> I will no longer utter my surprise about this. I got the message. You
> documented the point of view of the software craftsmanship movement on
> this matter very clearly. Thanks for that.
I do not speak for the software craftsmanship movement. See above.
> PS: To answer the recurring question for my definitions of terms like
> software architecture or software design: I don�t have a hard and fast
> definition. Nevertheless I believe that�s a flaw in my understanding.
> So I�m trying to improve in this regard.
> Thus I thought I ask the bright minds here in this list for help. As
> it turned out, though, they�re not sharing my feeling of the lack of a
> definition being a flaw. And they were not able to convince me of
> their point of view. (Neither could I convince them of mine.)
Well, here's my thinking. Put your cards on the table with your best
definitions and let's work on them. Quit complaining to us for not
working your problem without your help. Get in the game.
Ron Jeffries
www.XProgramming.com
That's my opinion and I agree with it. -- Julio Santos