design choices v. implementation details
Chet Hendrickson
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.
--
Best regards,
Chet Hendrickson mailto:li...@hendricksonxp.com
Check out our new courses at http://www.hendricksonxp.com
Kalle Launiala
George Dinwiddie
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
----------------------------------------------------------------------
Kalle Launiala
torstaina 7. heinäkuuta 2011 20.25.39 UTC+3 George Dinwiddie kirjoitti:
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.
philip schwarz
The distinction made by Holub [1] between 'Object-Oriented Design' and
'implementation details' seems pertinent.
In "Holub on Patterns - Learning Design Patterns by Looking at
Code" [2], we see that by OO design, Holub means the result of a
process which, when simplified for a classrom environment, boils down
to the CRC Cards approach: http://c2.com/doc/oopsla89/paper.html
devised by Kent Beck and Ward Cunningham.
Holub says:
#################################################
"In class, Beck and Cunningham picked a use case and made a best
guess
at determining which objects would be required to "act out" the use
case. They typically started with two objects and added others as
required as the scenario played out. People from the class were
selected to be those objects and where handed a copy of the
associated
CRC card. If several objects of a given class were needed, several
people represented those objects. The students literally acted out
the
use case...Here are the rules I use when acting out a use case with
CRC cards: ... perform the activities that comprise the use case by
talking to one another...you can talk only to your
collaborators...ETC
ETC (see paper linked above for more details)...Once you have worked
out a conversation that solves the problem, TURN ON A TAPE RECORDER
OR
TRANSCRIBE IT. THAT TRANSCRIPTION IS THE PROGRAM'S DYNAMIC MODEL. THE
FINISHED SET OF CRC CARDS IS THE PROGRAM'S STATIC MODEL. More often
than not, designers develop the dynamic and static models in UML,
using some formal process (for example, RUP, Crystal, and even some
flavours of Extreme Programming). The point is that an OO system is a
conversation between objects"
#################################################
So for Holub, DESIGN = DYNAMIC MODEL + STATIC MODEL.
About Design Patterns, he says the following:
#################################################
Design patterns are typically implementation details that are
applied by OO programmers when they translate the initial design to
code.
...
So please don't confuse the topics discussed elsewhere in this book
with the OOD process as a whole. Patterns are just a small part of
the
puzzle - and in some ways an insignificant part. This isn't a book
about OOD - it's a book about moving an OO design toward a concrete
implementation.
#################################################
So he considers his book on Design Patterns to be a book about the
implementation details we deal with in order to turn a design into a
concrete implementation.
Compare Holub's wiewpoint with the following section from Design
Patterns:
###############################
...The hard part about object-oriented design is decomposing a system
into objects. The task is difficult because many factors come into
play: encapsulation, granularity, dependency, flexibility,
performance, evolution, reusability, and on and on. They all influence
the decomposition, often in conflicting ways.
Object-Oriented design methodologies favour many different approaches.
You can write a problem statement, single out the nouns and verbs, and
create corresponding classes and operations. Or you can focus on the
collaborations and responsibilities in your system. Or you can model
the real world and translate the objects found during analysis into
design. There will always be disagreements on which approach is best.
Many objects in a design come from the analysis model. But object-
oriented designs often end up with classes that have no counterparts
in the real world. Some of these are low-level classes like arrays.
Others are much higher-level. For example, the Composite pattern
introduces an abstraction for treating objects uniformly that doesn't
have a physical counterpart. Strict modeling of the real world leads
to a system that reflects today's realities but not necessarily
tomorrow's. The abstractions that emerge during design are key to
making a design flexible. Design patterns help you identify less-
obvious abstractions and the objects that can capture them. For
example, objects that represent a process or algorithm don't occur in
nature, yet they are a crucial part of flexible designs. The Strategy
pattern describes how to implement interchangeable families of
algorithms. The State pattern represents each state of an entity as an
object. These objects are seldom found during analysis or even the
early stages of design; they are discovered later in the course of
making a design more flexible and reusable.
###############################
While the passage does not say that design patterns are an
implementation detail, it does seem to me to align to some extent with
Holub's view by distinguishing between early design, and a later phase
of design that is about making a design more flexible and reusable.
This later phase could maybe be said to be meta-design, since it is
about modifying a design to make it exhibit certain 'ilities'.
[1] http://www.holub.com/
[2] http://www.amazon.com/Holub-Patterns-Learning-Design-Looking/dp/159059388X
[3] http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
Philip
Ralf Westphal
choice. Also if we know that we can tell what´s an implementation
detail, because it´s not visible in the design.
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?
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).
Ron Jeffries
> 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
Ralf Westphal
> Hello, Ralf. On Friday, July 8, 2011, at 1:27:45 AM, you wrote:
>
> > 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 ...
But let me not answer you directly. Rather I´d like to ask another
question first: What´s design anyway?
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.)
So is there a special time for designing? Is there a special scope for
designing?
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"?
Ron Jeffries
> 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.
David Wilde
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.
Ron Jeffries
> 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?
Andy Dent
On 10/07/2011, at 3:24 AM, David Wilde wrote:
> 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.
Ralf Westphal
> 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.
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.
>
> 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.
levels of abstraction from a 30,000 feet view of a software system to
the statements in a method?
> 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.
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.
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?
Peter Bell
On Jul 10, 2011, at 9:23 AM, Ralf Westphal wrote:
> 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
Ron Jeffries
> 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
Ron Jeffries
+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
Ralf Westphal
realm of design?
While execution of decisions does not?
Are then all decisions the same, equally important, of identical
impact, on the same level?
Or can we discern different levels/kinds of design, e.g. architectural
design vs. some other design?
Peter Bell
On Jul 11, 2011, at 12:03 AM, Ralf Westphal wrote:
> 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
Esko Luontola
> 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.
array. Using the right syntax for the for loop in that programming
language is not design. But choosing whether to name the loop variable
"i" or something else is design.
If the loop variable is not interesting from the method's point of
view - it's just used to go through each value in the array (and the
programming language does not have a syntax for a for-each loop) -
then I would name it "i" in order to communicate its role and little
importance (assuming that's the convention in that particular
programming language).
But if the loop variable signifies a domain concept, or it is used in
an unusual way, then I would name it something else which communicates
its role and highlights the special importance of the loop variable
(if it's not "i" then the reader will be drawn to pay more attention
to it and figure out why it is not named "i").
David Wilde
Ron Jeffries
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)
Raoul Duke
> To illustrate, let's say I'm writing a for loop to iterate over an
> array. Using the right syntax for the for loop in that programming
> language is not design.
hah! wrong! :-)
Curtis Cooley
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
Michael Feathers
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
Ron Jeffries
> 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!
Raoul Duke
>> On Mon, Jul 11, 2011 at 1:59 AM, Esko Luontola <esko.l...@gmail.com> wrote:
>>> To illustrate, let's say I'm writing a for loop to iterate over an
>>> array. Using the right syntax for the for loop in that programming
>>> language is not design.
>> hah! wrong! :-)
> Excellent. Please tell us some ways that it is design. I'm sure
> it'll lead to some interesting discussion.
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.
Keith Brown
Ralf Westphal
> 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.
Rather what I´m interested in is seeing if the guys building the most
complicated systems in the world have a clear understanding of what
they are doing. Do they have a clear domain terminology for their
stuff? Can they discern different activities? Can they explain what
they are doing?
Software craftsmanship is about communication.
And it´s about transmitting competency.
I believe that competency is much easier transmitted, if the body of
knowledge in question is not only applied in expert manner
(uncouscious ability) but also reflected and constantly scrutinized
and wrapped in clear language.
The term design, though, to me seems to be be ubiquitous - but
notoriously underspecified. Everyone is using it - but what exactly is
this "thing" "design" or this activity "to design"?
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".
There is another interesting term: architecture.
What exactly is software architecture? Are there decisions which
specifically belong to the realm of software architecture?
Think of a 10 year old child asking you: "What are you doing all day,
Curtis?" And you´d answer, "Well, Shelly, we´re programming computers
so that they do marvellous things for us."
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 ;-)
Now assume the term "design" had slipped out: "Well, Shelly, I´m
designing software."
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.)
What I encounter again and again when assessing teams is that their
usage of language is imprecise and differing. It´s almost like in
Bable.
Eric Evans has made clear how important a customer domain language
(ubiquitous language) is. But that´s sure not the only language used
in teams. There is a natural language in use - and not always all team
members are equally capable of speaking/understanding this language
(think of multinational teams). And there is an overall technical
language in use: the language of software development. And again there
can exist larger differences between team members in speaking/
understanding it. This ranges from "What does 'stable sorting
algorithm' mean?" to "What is software architecture?" (and do we need
one?) to "What is design if we´re supposed to create it with TDD?" to
"What does this symbol on the whiteboard mean?"
Conscious and precise use of language to me is the foundation of any
collaborative effort.
And as long as there are people on a team who cannot define a much
used term precisely I fear there´s trouble ahead.
That hasn´t to do with missing trust. It has to do with not
understanding each other.
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.
Esko Luontola
> On Mon, Jul 11, 2011 at 3:50 PM, Ron Jeffries <ronjeffr...@acm.org> wrote:
> >>> To illustrate, let's say I'm writing a for loop to iterate over an
> >>> array. Using the right syntax for the for loop in that programming
> >>> language is not design.
> >> hah! wrong! :-)
> > Excellent. Please tell us some ways that it is design. I'm sure
> > it'll lead to some interesting discussion.
>
> 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.
the code would compile. For example, choosing between one of the
following syntaxes is a mechanical decision based on the current
programming language and thus not a design decision:
for (int i = 0; i < foos.length; i++)
for (var i = 0; i < foos.length; i++)
for i := 0; i < len(foos); i++
for i in 0..(foos.size - 1)
for (i <- 0 until foos.length)
But choosing from where to where loop, whether to loop forwards of
backwards, using < or <=, using for-each loop or indexed loop etc. are
design decisions, because they can be used to communicate different
intents about the code.
Ron Jeffries
> 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
Adam Sroka
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.
> Hello, Ralf. On Tuesday, July 12, 2011, at 1:25:33 AM, you wrote:
>
>> 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.
>
>> 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
>
Ron Jeffries
> 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
David Wilde
Peter Bell
On Jul 12, 2011, at 12:25 AM, Ralf Westphal wrote:
> 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
Raoul Duke
> the code would compile.
my apologies for mis-interpreting your intention.
sincerely.
Ralf Westphal
> 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.
contrast to implementation or whatever.
If soccer (or football) distinguishes between offence and defence then
that´s, well, two different activities. And they stay different even
though a team (or a single player) constantly needs to follow them.
Acting properly in terms of defence means someting different from
acting properly in terms of offence.
A soccer trainer certainly will advise the players differently what to
do for a proper offence or defence.
And whether the team switches between offence and defence in a
timeboxed manner (probably not very effective ;-) or whether they all
constantly keep an eye on offence and defence or whether certain
players are responsible for watching offence requiring patterns vs
defence motivating patterns in the game... that´s a different decision
altogether.
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.
Please name a single question which to you belongs in the realm of
software architecture.
Please name a single question which to you belongs in the realm of
software design.
Please name a single question which to you belongs in the realm of
software implementation.
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.
I´m asking just for questions because my guess is they are easier to
give than abstract definitions.
Ron Jeffries
wrote:
> 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.
Curtis Cooley
> Hello, Ralf. On Wednesday, July 13, 2011, at 3:17:56 AM, you
> wrote:
>
>> 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.
>
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.
Adam Sroka
> On Wed, Jul 13, 2011 at 6:43 AM, Ron Jeffries <ronje...@acm.org> wrote:
>> Hello, Ralf. On Wednesday, July 13, 2011, at 3:17:56 AM, you
>> wrote:
>>
>>> 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.
>>
>
> 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.
>
You must have very messy hair :-D
Ralf Westphal
"Why should we structure our domain terminology? What´s the use for
different terms like architecture, design, implementation? 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.
Every developer should be able to decide every question at all times
whenever it comes up.
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.
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.
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.
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.
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.
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. 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.
Master pilots need no special terminolgy to be experts. They just do
it. Master craftsmen don´t need special terminology to be experts.
They just do it. So you better watch and learn and try for yourself."
Is that about right?
Ron Jeffries
> 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
Ralf Westphal
> 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.
In the end, sure, we´re all doing the same, regardless of how rich our
languages are. Software development means to answer all sorts of
questions from "Should we use technology X or Y for inter-process
communication?" to "Should I use data structure X or Y to store the
data?" and "Should this be done with a while() or for() loop?" or
"Should the functionality be split across processes?"
As long as you´re just thinking about this yourself, language is not
important. You´ll be working with mental pictures of your material at
hand.
But once you start talking to other people about this, language
becomes important. And sure, language always starts with concrete
terms. Tangibles get named.
Look at the history of language itself. First there was, well, no
language ;-) Then there was concrete language. For a very long time
people only talked.
But then - lo and behold! - people started to talk about (!) language.
I think it was the Greeks who invented grammar and rhetorics. They
found it helpful to climb onto a meta-level to teach language skills
of all sorts. And then onto yet another meta-level: philosophy.
The same development - to me - seems to be natural for software
development.
Any profession of some history and success develops meta-languages.
"Software architecture" and "software design" and "model" and
"pattern" are part of this meta-language, I´d say. Even though, they
might not be precisely and universally accepted defined. At least they
are in common use - even though you personally might not find them
helpful.
That´s why I think it beneficial for our industry to either
"officially" get rid of them. ("Guys, we don´t need no fuzzy concepts
and lofty language. Let´s do away with the terms 'architecture' and
'design'. Just do the right thing.")
Or to increase the effort to find practical and useful definitions for
them.
It just helps to convey the body of knowledge of your industry if
there is a precise and differentiate 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 beliefs.
Keith Brown
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.
Ron Jeffries
> 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
Ralf Westphal
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.
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?
I keep hearing the members of this list using the term "design" (like
in "Test-Driven Design").
So I´m curious and just asked for a definition of this and some other
terms.
And the answer was: "There is no (hard and fast) definition and we don
´t really need any, since we don´t need to distinguish different
'modes' or 'activities' during software development - at least not in
this regard. We need to distinguish between refactoring and non-
refactoring, and maybe we need to distinguish between concrete and
abstract. But that´s it."
That´s ok for me. I told you why I was asking, why I think definitions
are important (and natural).
But I take away your answers and will think about them for a while.
To try to find definitions here in this forum seems to lead nowhere,
since the members don´t believe in such definitions.
That´s fine. I´ll turn elsewhere.
Ron Jeffries
> 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
John Jan Popovic
As it was noticed before by Chet, for me particularly interesting would be to explore the line which brings a distinction between a design choice and an implementation detail.
It would be nice to know when we can be pretty sure to claim: IT IS NOT A DESIGN CHOICE, IT IS "JUST" AN IMPLEMENTATION DETAIL.
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
Ralf Westphal
> 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.
parent always is "naturally interessted" in the subject about which
the child is inquiring. (Maybe not by itself, but because the child is
asking.)
The group here, though, is outspokenly not interested in defining
terms like architecture or design. As it turns out it´s highly
skeptical a discussion about them it worthwhile.
To be honest: I had suspected this, but wanted to be sure.
Adam Sroka
and I'll tell you why: I'm pretty sure that if we defined them and we
narrowed it down to the level of something we all do, that it would
turn out to be something we should NOT do. For expedience, I'd rather
just say "design" and mean what I do that works for me, and you'd mean
what you do that works for you, and in the end the code will speak for
itself.
Philip Schwarz
>What I encounter again and again when assessing teams is that their
>usage of language is imprecise and differing.
From "Documenting Software Architectures[1]: "Although the term
software architecture has multiple definitions, no universal
definition exists. The Software Engineering Institute's Web Site
collects definitions from the literature and from practitioners; so
far, more than 90 definitions have been collected."
Here are two of the goals of the SEMAT initiative [2], led by Ivar
Jacobson, Bertrand Meyer, and Richard Soley:
* defining the software engineering discipline
* identifying the universal elements of software engineering
I am really interested to see what the 'universals' will be around
design and programming. See Figure 1 in SEMAT's Vision statement [3]
The group who is working on the "Kernel", which includes the
"universals" has a Google group [4].
[1] http://www.amazon.co.uk/Documenting-Software-Architectures-Beyond-Engineering/dp/0321552687
[2] SEMAT http://www.semat.org
[3] Vision Statement http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf
[4] http://groups.google.com/group/semat-kernel-language-track
Philip
Ron Jeffries
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
Stephan Schwab
> The group here, though, is outspokenly not interested in defining
> terms like architecture or design. As it turns out it´s highly
> skeptical a discussion about them it worthwhile.
>
> To be honest: I had suspected this, but wanted to be sure.
that the people here have come to understand that making software is
essentially a craft and not an engineering discipline. It is more the
approach artisans take.
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.
Philip Schwarz
> 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.
Some time ago I bought 'What Every Engineer Should Know about Software
Engineering' [1] because I was impressed that it mentioned the GRASP
patterns, the SOLID principles, TDD, refactoring, and Fowler's Code
Smells, but I was shocked to find out that it perpetuates this
division of labour.
Here is what it says about coding:
###############################################
SW engineers probably spend less than 10% of their time writing code;
the other 90% of their time is involved with other activities that are
more important than writing code...many SW engineers specialise in a
small subset of these activities, for example, software testing...
...someone who spends the majority of his or her time GENERATING code
is more aptly called a "programmer"...just as wiring a circuit
designed by an electrical engineer is not engineering, writing code
designed by a sw engineer is not an engineering activity...
...There are many other ancillary activities to sw engineering, one of
which is the programming of the code...the writing of code can be the
least engineering-like activity that a software engineer can
undertake...
###############################################
But then I am not sure how in touch he is with the things he writes
about, e.g. of XP he wrote: "some of my students use it ...and report
that it is effective, fun, and easy to use".
Does he realise that the opening sentence of Erich Gamma's Foreword to
Kent Beck's "Extreme Programming Explained" says: "Extreme Programming
nominates coding as the key activity throughout a software project."
Philip
[1] http://www.amazon.com/Every-Engineer-Should-Software-Engineering/dp/0849372283
On Jul 11, 9:11 pm, Curtis Cooley <curtis.coo...@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 9:03 PM, Ralf Westphal <i...@ralfw.de> wrote:
> > So do you mean, any decision while developing software belongs to the
> > realm of design?
> > While execution of decisions does not?
>
> > Are then all decisions the same, equally important, of identical
> > impact, on the same level?
> > Or can we discern different levels/kinds of design, e.g. architectural
> > design vs. some other design?
>
> Ralf,
> 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.
>
> 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.coo...@gmail.com
Philip Schwarz
you said:
>Any profession of some history and success develops meta-languages.
>"Software architecture" and "software design" and "model" and
>"pattern" are part of this meta-language, I´d say. Even though, they
>might not be precisely and universally accepted defined. At least they
>are in common use - even though you personally might not find them
>helpful.
>That´s why I think it beneficial for our industry to either
>"officially" get rid of them. ("Guys, we don´t need no fuzzy concepts
>and lofty language. Let´s do away with the terms 'architecture' and
>'design'. Just do the right thing.")
>Or to increase the effort to find practical and useful definitions for
>them.
>It just helps to convey the body of knowledge of your industry if
>there is a precise and differentiate language.
architecture, design, and model, etc. Here is the goals section of
their original Vision Statement:
The work will proceed along five different tracks:
1. Definitions: defining software engineering discipline. captures all
interesting methods, practices in software production today and can
be adapted for future evolution
2. Theory: identifying the theories (in particular from mathematics)
that provide essential help.
3. Universals: identifying the universal elements of software
engineering, which must be integrated into the Semat kernel.
4. Kernel language: defining the language for describing the
universals, practices and patterns.
5. Assessment: techniques for evaluating software engineering
practices and theories, including the results of Semat.
All tracks should produce some visible results within twelve months,
but the extent of these results may vary widely. Most in need of short-
term results are track 3 and 4, as we must identify kernel elements to
serve as the basis for the entire work, help the software industry
reduce the jumble of methods, and improve the teaching of software
engineering.
[1] SEMAT http://www.semat.org
[2] SEMAT Vision Statement http://www.semat.org/pub/Main/WebHome/SEMAT-vision.pdf
Philip
Philip Schwarz
>actively interested in examples where tighter definitions of these
>terms would be beneficial.
Philip Schwarz
> 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.
and I nodded.
I read what Esko wrote:
>choosing whether to name the loop variable
>"i" or something else is design.
and I nodded.
I read what Michael wrote:
>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.
an I nodded.
But then I remember what Kent Beck said in his latest book,
Implementation Patterns. Here is my summary of part of the
'Motivation' chapter:
####################
Forces affect how code is written.
E.g. there are few reasonable ways to write a loop.
Each of them implies different priorities between the constraints.
Examples of Forces/Factors/Concerns/Constraints:
* easy to read
* easy to write
* easy to verify
* easy to modify
* efficient
If performance is more important, you may structure the loop one way,
while if ease of modification is more important, you might structure
it differently.
Implementation patterns help you write code.
Each pattern bundles a common problem of programming with a discussion
of the factors affecting that problem and provides concrete advice
about how to quickly create a satisfactory solution.
Each pattern illustrates a point of view about the relative priorities
about the forces.
####################
In the book's preface he says:
####################
This is a book about programming—specifically, about programming so
other people can understand your code
...
It is not a design book because it is mostly concerned with smaller
scale decisions, the kind programmers make many times a day.
####################
Philip
On Jul 11, 9:43 pm, Michael Feathers <michael.feath...@gmail.com>
wrote:
> On Mon, Jul 11, 2011 at 2:23 PM, Raoul Duke <rao...@gmail.com> wrote:
> > On Mon, Jul 11, 2011 at 1:59 AM, Esko Luontola <esko.luont...@gmail.com> wrote:
> >> To illustrate, let's say I'm writing a for loop to iterate over an
> >> array. Using the right syntax for the for loop in that programming
> >> language is not design.
>
> > hah! wrong! :-)
>
> 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
George Dinwiddie
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
----------------------------------------------------------------------
Keith Brown
My definition of design is making a choice between reasonable alternatives. My definition of architecture is designing buildings.
--
Keith Brown
CTO | pluralsight.com | .net training for the modern developer
801.447.2592 | skype: keithbrown42 | ke...@pluralsight.com
http://twitter.com/keithbrown42 | http://www.facebook.com/keithbrown42
Ralf Westphal
> The title of this group contains the word "craftsmanship". That means
> that the people here have come to understand that making software is
> essentially a craft and not an engineering discipline. It is more the
> approach artisans take.
>
> 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.
precise vocabulary because they engage in "show, don´t tell"
activities? They wave hands instead of using specific terms?
Ralf Westphal
> But then I remember what Kent Beck said in his latest book,
>
> ####################
> This is a book about programming—specifically, about programming so
> other people can understand your code
> ...
> It is not a design book because it is mostly concerned with smaller
> scale decisions, the kind programmers make many times a day.
> ####################
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.
Peter Bell
On Jul 18, 2011, at 11:16 AM, Ralf Westphal wrote:
> On 17 Jul., 18:43, Philip Schwarz
> <philip.johann.schw...@googlemail.com> wrote:
>> But then I remember what Kent Beck said in his latest book,
>
>> In the book's preface he says:
>>
>> ####################
>> This is a book about programming—specifically, about programming so
>> other people can understand your code
>> ...
>> It is not a design book because it is mostly concerned with smaller
>> scale decisions, the kind programmers make many times a day.
>> ####################
>
> 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.
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
Ralf Westphal
> 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."
straightforward question: What´s the definition of the terms "software
architecture" and "software design" of the sw craftsmanship movement?
No definition has been given to me so far. So I haven´t refused any
"rocks".
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.
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.
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
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."
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?
Peter Bell
On Jul 18, 2011, at 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?
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
David Wilde
David Wilde
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?
George Dinwiddie
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.
Curtis Cooley
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
Dave Rooney
> 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
Ben Fulton
<keith...@pluralsight.com> wrote:
> On Sun, Jul 17, 2011 at 3:45 PM, George
> Dinwiddie <li...@idiacomputing.com> wrote:
>>
>> My definition of design is making a choice between reasonable
>> alternatives. My definition of architecture is designing buildings.
>
> Well said. This resonates well with me.
>
One definition of architecture that I liked was "design decisions that
aren't easy to change later".
Curtis Cooley
So in a craftsmanship and agile world, this definition is important
because now architecture is something we'd want to do less of?
Ron Jeffries
> 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
Ron Jeffries
>> 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
Ron Jeffries
> 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
Ron Jeffries
www.XProgramming.com
Do only what is necessary. Keep only what you need.
Philip Schwarz
Curtis said:
>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.
you are so concerned about not having an exact definition.
Philip
On Jul 18, 7:29 pm, Curtis Cooley <curtis.coo...@gmail.com> wrote:
David Wilde
aren't easy to change later".
Esko Luontola
> *One definition of architecture that I liked was "design decisions that
> aren't easy to change later".*
> I actually really like this definition.
That definition is mentioned in http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
where it is said in the form "things that people perceive as hard to
change." In that definition the _perception_ of people also plays a
part - things that are hard to change for some might not be for others
who know better ways of doing things or are more skilled in them (the
example of a database schema is mentioned in the article).
David Wilde
--
Ralf Westphal
> 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.
always treating the whole person."?
You don´t care if he can distinguish between anatomy and physiology?
You don´t care if he can tell surgery from anaesthetics? Why should he
differentiate between possible somatic and psychological causes for
depression? Why have psychiatry and neurology?
Of course I like to be treated as a person, too, instead of being just
a case, just "the liver from room #13".
But in addition I like my doctor to be able (!) to tell mental problem
from somatic problem, to be able to distinguish between a lot of
different aspects of my body and my mind.
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".
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.
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.
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 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.
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.)
Alan Gardner
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
Ron Jeffries
> 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