Readability and Simplicity (Was: Principles of Software Craftsmanship?)
Curtis Cooley
>
> I'm interested in the stuff we really KNOW and that can be tested as
> principles that could underpin what we do, for example:
>
[snip]
> 2. We KNOW that the more complex code is, the more ways there are for
> it to be wrong than right, and therefore the higher the probability of
> bugs. So we strive to keep things as simple as possible.
>
> 3. We KNOW that when code is difficult to understand, it will take
> much, much longer to make changes to it, with a much higher likelihood
> of introducing bugs. So we strive to make our code as easy to
> understand as possible.
I completely agree with these statements, but what I struggle with in
my work is with what my fellow developers consider complex/simple and
readable/unreadable.
I work with a couple of guys who are very very smart, but they come
from strong procedural backgrounds so they actually find huge methods
with deeply nested ifs easier to understand than a modular more OO
solution. Whenever they Ctrl-Click on a method and end up in an
interface, they deem that unreadable and hard to follow. They find
switch/case easier to read than command pattern.
How do you bring craftsmanship values to a team that either can not or
will not make the effort to grok OO and make that next leap?
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.
Tim Ottinger
> I completely agree with these statements, but what I struggle with in
> my work is with what my fellow developers consider complex/simple and
> readable/unreadable.
>
> I work with a couple of guys who are very very smart, but they come
> from strong procedural backgrounds so they actually find huge methods
> with deeply nested ifs easier to understand than a modular more OO
> solution. Whenever they Ctrl-Click on a method and end up in an
> interface, they deem that unreadable and hard to follow. They find
> switch/case easier to read than command pattern.
>
More modular doesn't mean "oo". A well-modularized non-OO
is still cleaner than a deep stack of if-then-else.
Have them try to write tests for a single aspect of a big method
with specific circumstances, and then see if it looks all that simple.
> How do you bring craftsmanship values to a team that either can not or
> will not make the effort to grok OO and make that next leap?
>
>
OO has nothing to do with it. If you drag in baggage, you might
lose them. Testability is more important.
That having been said, OO is more testable IME than non-OO
due to ability to create test doubles.
Maybe the ability to test is a better handle? But if they don't want
to test, I don't know what you can do right now.
I think that the pain of testing ugly code is a pretty good spur toward
writing clean code.
Curtis Cooley
> Maybe the ability to test is a better handle? But if they don't want
> to test, I don't know what you can do right now.
>
> I think that the pain of testing ugly code is a pretty good spur toward
> writing clean code.
>
We test. We test a lot. The problem is these are rollupyoursleeves
shouldertothegrindstone guys. If its hard to test, they just work
harder to test it.
I'm not sure, but I think there is another category of 'Joe' that
we've missed. The 'Joe' that shows up to work and works hard, all day,
then goes home feeling good 'cause he worked hard that day. It doesn't
matter whether he worked hard fixing yesterday's bugs or implementing
today's features. he worked hard, dammit, and that's what matters.
Raoul Duke
> we've missed.
that sounds like a good point!
an a related example/anecdote: i believe there are Joes and Joettes
who write Bad Code in fact because they are Quite Smart at least in
the sense of having Really Good Memories. like, they are able to
comprehend the Rube Goldberg machine that is before them in a 4000
line file with 200 line functions in an overall wildly gyrating
system. if something bad happens, if there is a bug, rather than
figuring out a refactored simplified version, they instead patch the
daylights out of the code with more conditionals.
these people aren't dumb. they are too 'smart' in some sense, i think. :-)
sincerely.
Markus Gaertner
haven't manages so far, since most of the company's value is taken on their
pride (which makes my life very harder, of course).
Kind regards
Markus Gärtner
Curtis Cooley
That's exactly what I've witnessed. Another indicator is that these
Joes can comprehend any huge method/class but the context switch of
opening another file is too much. Which is why they like putting all
the code in one class/method. They can scroll up and down a class and
not lose focus, but if they have to switch to another file, or worse
another interface, they've lost everything they were keeping in their
head.
Like there's an infinite sized one file buffer in their heads.
Arbitrarily long files are stored with no problem, but to load another
file, the current file has to be deleted.
So, perhaps teaching them some index card tricks, like CRC perhaps, so
they don't have to keep the model in their head? I'll try this next
time I pair. Just do some CRC as we browse the code so the model is on
the table in front of us and does not have to be kept in our heads. I
know that would help me a lot.
Maybe the pain of listing 54 responsibilities on one card might help as well ;)
Raoul Duke
One thing I forgot to mention, an important lesson for us all, I feel:
We should be careful about what we define as good/bad or un/acceptable
approaches and ways to think about things. We need to know what things
really are problems vs. what things are subjective and should be left
to personal choice + should be aided via tooling. I for one do not
wish to live in a One Way To Do It world, that seems really lame when
in theory computers could be put to use to help us make things be more
inclusive.
As a vaguely concrete example, consider the question of One Big File
vs. Lots of Little Files. I think it is pretty safe to say that both
approaches have their pros and cons. I believe that a problem we have
is that our tools force us to choose one or the other, we can't
currently have it both ways. That means we have to pick the least of
two evils, in some sense. If we had tools which could e.g. flip
between different "perspectives" on the code, we could support not
only people who habitually prefer one way, but we could allow each
person to try different modes, which can come in really handy at
different times.
sincerely.
Jason Gorman
size and bugs:
http://www.cistel.com/free_expertise/publications/Cistel-2002-01.pdf
Jason Gorman
http://www.softwarecraftsmanship.org.uk
Torbjörn Gyllebring
> will not make the effort to grok OO and make that next leap?
I do most my paid work on OO systems and consider myself quite
capable at it but I find theese lines highly insulting.
I've signed the manifesto, maybe missed the fine-print though, and
didn't see anything saying that OO was required for something to be
craftmanship worthy.
Personally I find it highly disturbing that much of the discussion
presently focuses on two things, OO as "the only way that could
possibly work" and "TDD is the only way to responsibly develop
software". Now, Im a huge fan of TDD practiced right and I consider OO
to be a highly successfull, wildly usefull way to build software, but
aren't we being a tad dogmatic? Procedural code can be modular, easy
to read and understandabl, functional programing can be succint,
clear, fast and downright beautiful. I consider having GUT's (Good
Unit Tests) better than simply using watared down "test first, forgot
the design" TDD.
As craftsmen don't we ove it to ourself, our peers and the greater
community to be open to diffrent ways, approaches and solutions? Isn't
that the whole point?
Now, if their code is completly untestable and doesn't harmonize with
the rest of the system, now that's an issue.
Jason Gorman
them, for similar reasons. I experimented with a pledge designed not
to alienate people who care as much as we do but do things a different
way:
www.icareaboutsoftware.org
(I have a huge backlog of signatures to post, BTW - if you pledged but
your name isn't up there yet)
Jason Gorman
On Mar 11, 9:29 pm, Torbjörn Gyllebring
Curtis Cooley
write Java. Modularizing procedural code in Java means making more
classes and methods. Functional programming in Java isn't going to
work unless the language moves towards making it the norm.
That said, I never meant to say OO is the only way to be a craftsman.
I admit that maybe it sounded that way, and I apologize if it did. I
guess I was using a shortcut for "code that is completely untestable
and doesn't harmonize with the rest of the system." The rest of the
system is OO.
Your point is taken. I was mentored in craftsmanship by master's
fluent in OO, so I see good code as conforming to the SOLID principles
and crappy code as not. I'm admittedly biased towards OO, though I'm
always open to new and better ways. You are correct in that the
"movement" should be as well.
Jason Gorman
getting out there is that "software craftsmanship = XP done properly".
I'm an XP practitioner, and coach in practices like TDD and
refactoring and OO design, but my career goes back long enough to a
time when I worked on teams delivering very high quality software
using some very different techniques, so I know as a personal reality
that "software craftsmanship" is a much broader church.
I'm sure none of us wants to end up with a very narrow movement which
might alienate a whole bunch of very good programmers who haven't come
via the Agile highway. But I'm also old enough to have seen similar
movements crystallise into things that their originators - that's me
and you, folks - didn't intend and might even find they disagree with.
I'm seeing now that commentators are picking up on the "software
craftsmanship" meme and dicing and slicing our diverse, complex,
colourful and sometimes conflicting views until they're simple, 2-
dimesnional, monochrome ideas that reddit.com users can easily digest
(and then pour scorn on, usually). And, judging by the heated debates
on newsgroups, blogs and the Twitterverse that I've witnessed, the
simplified, 2-dimensional, monochrome version of "software
craftsmanship" is that it's basically TDD (but done to a degree of
rigour that the majority of people who claim they're already doing it
seem to balk at).
This SC = TDD++ straw man looks dogmatic, because - if that's what we
really thought (which we don't, of course) - it really would be
dogmatic. And if word like that spreads it'll kill craftsmanship stone
dead, because "dogma" (like "perfectionism") is a word that causes
managers and customers and many of ou8r peers to foam at the mouth and
go batsh*t crazy.
Movements have a tendency for the concrete to set so fast when they
finally take off that the participants are left with their names
permanently etched on something they didn't really mean and can't take
back no matter how hard they try.
I would like to see if we can take a step back, look at the end goals
we're setting out to achieve as craftsmen, and show that there are
many routes to the kind of results we wish to achieve.
Raoul Duke
> we're setting out to achieve as craftsmen, and show that there are
> many routes to the kind of results we wish to achieve.
mod parent up!
Heinrich Breedt
OO as "the only way that could
possibly work" and "TDD is the only way to responsibly develop
software".
Heinrich
Torbjörn Gyllebring
* You're using a functional language like F#, L#
* You're using a multiparadigm language like C++
* You're using a stackbased language like Forth (DeltaForth, MrLooseForth)
* You're using C# with Linq or other declarative and functional extensions.
The language is a tool to solve a problem, dependeing on the domain,
your internal wireing and the environment you're developing in and how
you choose to view that probel multiple equally testable, performant
and clean solutions are possible. Now I wouldn't advice anyone to go
counter their team, introduce a new language just for fun or anything
like that. The odds are that if you're working in something like 95+%
of the .NET shops I've seen you're doing C# and you better do it in an
OO fashion and you probably should spend a great deal of time getting
good at objects.
2: Can code responsibly be written without TDD, here meaning:
* Never write production code without a failing test.
* Never write a test without a essential need.
* Never identify a need without a customer.
* Merciless refactoring.
* Follow the Feathers commandments on what is a unit test.
I would say yes, TDD is _how_ many of us choose to developsoftware but
arguing that it's "the only way" is somewhat silly. Now Im pro TDD, I
consider it the currently best way to deliver well designed, testable,
valuable software without advertly diminishing the future prospects of
extension and further evoltuion of the codebase. But looking around I
see successfull projects almost everywhere that Im quite sure wasn't
TDD'ed into exsitence, seems like there's quite a bit of compilers,
operating systems, tools, libraries, API's out-there, things I really
hope ought to be responsibly developed and very few of them seems to
list "TDD'ed therefore it works" as the major sellingpoint. I make my
living writing .net code and judging from the fact that large parts of
the framework are sometimes hard to test, and sometimes downright
test-hostile Im forced to conculde that it probably wasn't TDD'ed, now
either I have to conculde that I base my living on an inherently
unprofessional product, that my compiler could brake at every turn and
that im just lucky that anything works. Or I must alter my view to
include non TDD'ed code as something that actually seems to at times
happen and actually does work.
Maybe Im wrong but doesn't it seems just a bit unproffesional to claim
to being a professnional while using unprofessional tools, techniques
and materials, not by neccessity, but by choice?
If so then maybe we need to start developing our own compilers,
frameworks, vcs's and join the "It's TDD all the way down"-society.
Best Regards
Torbjörn Gyllebring
Jason Gorman
ways of achieving OO benefits in non-OO languages.
On the subject of TDD, when I'm selling the approach I find it very
useful to step back and sell the benefits of TDD and get buy-in on
those before I propose my test-driven solution. I'm old enough to know
that there are other ways of achieving the same benefits. For example,
Design By Contract has a good track record for producing reliable code
and (with a combination of assertions and unit tests) for detecting
regressions quickly and cheaply. Cleanroom unquestionably produces
very high quality code. As did Fusion, Syntropy, Catalysis and - let's
be honest - RUP when it was being effectively applied. In reality, of
course, these methods and practices worked when the people applying
them knew what they were doing and exercised discipline in applying
them. Which, in my book, makes them craftsman.
I'm worried that our definitions are too narrow and focused on a
specific roadmap to mastering software development, rather than on the
destination itself. Personally, I see no reason why apprenticeships,
for example, MUST be the only route. I don't buy that, I'm afraid.
They are a good route, no doubt, and I support 100% the efforts of
companies like 8t Light in those sorts of programmes. But is it
possible to master software development without that model of
learning? Sure it is.
Can we please try to avoid the pitfall of defining "software
craftsmanship" as "mastering Extreme Programming and OO design through
an apprencticeship to a master"?
Jason Gorman
http://www.softwarecraftsmanship.org.uk
On Mar 12, 6:59 am, Torbjörn Gyllebring
>
> - Show quoted text -
Olof Bjarnason
deserves attention.
After all, not many (any?) of those attending the SC2009 at BBC have
gone through an "apprenticeship", I guess?
But I still applaud the apprenticeship-idea -- that idea is part of
craftmanship-ish franchises throughout the times of man. Software is
still a young craft and as such offer few places to be an apprentice
at.
So while I think a person can be a software craftsman without having
gone through an apprenticeship, I can see a future where the
advancement from "apprentice" through "journeyman" to "master" will be
quicker. Not everybody will have to do it the hard way, that is.
"Craftsman" doesn't have anything to do with where on that scale
someone is. A junior carpenter is a craftsman just as his senior
mentor with 20 more years in the craft.
For me the hope is that both apprentice and master will get a speed
and quality gain from performing their craft this way. As well as a
more fun and passionate work environment!
Not to mention more SC-conferences to visit 2010, 2011, ... :)
Min blogg:
http://olofb.wordpress.com
[My blog, in Swedish]
Paul Pagel
I actually worry now that - probably unintentionally - the message
getting out there is that "software craftsmanship = XP done properly".
I'm an XP practitioner, and coach in practices like TDD and
refactoring and OO design, but my career goes back long enough to a
time when I worked on teams delivering very high quality software
using some very different techniques, so I know as a personal reality
that "software craftsmanship" is a much broader church.
Paul Pagel
Carl Hume
Here is my principle:As an aspiring craftsman, I don't ship untested code. Everything I write has a test to prove it works.Here is the difference:I use TDD to insure I hold true to this principle (as well as for other reasons). But if someone doesn't use TDD, but another technique insuring their test coverage, I would say that person is still a craftsman. However, the value is that the tests MUST be there to prove your system works. I have found this not to be best practice, but the medical equivalent of washing your hands. My code will get infections without tests.
I have a similar principle. I ask the people I work with: "How do you know that it works?"
Today, most people answer that question with "all the tests pass", but I don't know how it will be answered tomorrow.
I'd suggest removing the implementation from the principle. "As an aspiring craftsman, I can prove everything I write works as intended."
Carl
Adewale Oshineye
audits? Or some other non-testing technique that still ensures
quality?
2009/3/12 Paul Pagel <pa...@8thlight.com>:
Paul Pagel
methods in practice. If they execute the code and prove they work,
then they are 'testing' it in some manner or another. But you are
right, the important thing here is that the code is proven to work.
Michael Wilson
Uhm... is this a hypothetical? Or do you actually know of a "non-testing
Adewale Oshineye
(for example FindBugs). It's still deeply flawed but one of the
attendees of the SC2009 conference in London was telling me that this
is his research area and there are some promising developments that
might actually be usable in a few years time.
The point is that TDD is not an end an itself and one day we may
develop even better ways of achieving our goals.
2009/3/12 Michael Wilson <madwill...@gmail.com>:
Michael Wilson
Adewale Oshineye wrote:
> Well there's lots of interesting research going on in static analysis
> (for example FindBugs). It's still deeply flawed but one of the
> attendees of the SC2009 conference in London was telling me that this
> is his research area and there are some promising developments that
> might actually be usable in a few years time.
>
> develop even better ways of achieving our goals.
>
But not today.
So far TDD for me is the single best way of doing it. Plus it yields so
much in terms of code structure that I'd be very surprised if I ever
stopped doing it. Of course I was very surprised when I STARTED doing
it, so there ya go. ;-)
I DO think (and my experience has shown) that a lot of people look for
reasons to avoid TDD because it's hard and they don't like having to
change deeply ingrained programming habits. Frankly that's what
happened to me. But your point is solid.
Enrique Comba Riepenhausen
Let's suppose FindBugs works after the developments in static analysis
have been successful.
TDD, at least for me, is a design exercise. When I start coding, my
TDD practice is the one which leads me to discover the name of the
class I am coding right at the beginning and which leads me to see
which shape my program is taking. It seems that at the same time I am
verifying that my code is working through the tests – nice feature of
my design tool of choice ;)
2009/3/12 Adewale Oshineye <ade...@gmail.com>:
Enrique Comba Riepenhausen
[@]: <eco...@gmail.com>
[w]: <http://www.nexwerk.com>
Kevin Taylor
Regardless Design by Contractors could reasonably consider themselves following good Craftsmanship principles.
Maybe the general principle is that "code behavior is verifiable?"
--
Kevin P. Taylor
312.380.6672
//obtiva - Agility Applied. Software Delivered.
http://obtiva.com
Michael Wilson
TDD is pretty crisply defined.
1. You are not allowed to write any production code unless it is to
make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is
sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is
sufficient to pass the one failing unit test.
Olof Bjarnason
> be an alternative to TDD or automated unit testing. I don't have personal
> experience with it.
>
> Regardless Design by Contractors could reasonably consider themselves
> following good Craftsmanship principles.
>
> Maybe the general principle is that "code behavior is verifiable?"
something is missing from that definition.
BTW I don't think this is leading us anywhere - stop arguing process!
Curtis Cooley
At the risk of sounding snarky, works != craftmanship
Casey Charlton
Enrique Comba Riepenhausen
the manifesto):
Not only working software, but also well-crafted software
> If your priority is well written code, you almost certainly have a different
> business goal from your employer. If you can achieve your business goals,
> *and* have well written, maintainable, elegant, and just downright sexy code
> too ... then all the better.
would fall into the category of an 'industrial programer'.
As most of us have mentioned before, there is nothing wrong about
industrial programming, but I don't think that that is what we are
looking for here...
Cheers,
Enrique
>
>
> 2009/3/12 Curtis Cooley <curtis...@gmail.com>
>>
>> At the risk of sounding snarky, works != craftmanship
>
> >
>
Nevin ":-)"
> As an aspiring craftsman, I don't ship untested code. Everything I write
> has a test to prove it works.
of the them.
Testing can prove the inverse; i.e., that code doesn't work. Testing
increases confidence that code is likely to be free of bugs and
defects. Testing helps minimize the risk in refactoring.
To say that you can prove something is a really strong assertion,
which just isn't applicable to testing.
--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404
Raoul Duke
>> has a test to prove it works.
>
> Testing has lots of benefits, but proving that code works is not one
> of the them.
right; saying that something is tested is not a straight-forward
guarantee that it is proven to work, for many reasons.
so i'd like to include something like: "as a Craftsman, I actually
know what my tests actually test, and what claims I can make based on
the results of those tests." (you can replace "test" with <tool> i
guess.)
sincerely.
Paul Pagel
tests specify. That is what the assertions do. When you run them,
they prove to you through examples that your code is executing and you
are getting the results you expected. Now, there is always scenarios
you miss or a faulty test, so it doesn't prove your application
works. Even with unit tests and integration tests, there is always
some scenario you can miss (and often do).
What I am trying to answer is these questions:
"How do you know your application works"
"How do you know that change didn't break something"
"How do you know there are no bugs"
Of course, as previously mentioned, your proof is only as good as your
tests.
Lance Walton
only proved it correct, not tried it.
-----
Lance Walton
http://www.stateofflow.com
http://homepage.mac.com/LanceWalton
On 12 Mar 2009, at 22:12, "Nevin \":-)\"" <nli...@gmail.com> <nli...@gmail.com
Dave Hoover
> I'd suggest removing the implementation from the principle. "As an aspiring
> craftsman, I can prove everything I write works as intended."
+1 Like it
Raoul Duke
>> craftsman, I can prove everything I write works as intended."
>
> +1 Like it
i still don't get it, it really seems to ignore reality, or just be
naive. "as intended" is way too general imho. for this over-arching
topic i think it should err more on the side of something like:
"I appreciate the significant value of comprehensive testing but am
wary of its limits, and endeavour to find appropriate balance in use
thereof."
sincerely.
Raoul Duke
that is better, in my view -- an issue i'm having here is semantics
and connotation. it bugs me when somebody says only "tests prove it
works" because that is logically bull-pucky for any system of
reasonable size.
when it is more clearly stated as you have here, then i'm not so
freaked out about it. :-) so i would encourage people to find a way of
saying what you said here w/out leaving out the crucial details like
"as the tests specify" and "it doesn't prove your application works".
sincerely.
Paul Pagel
>> craftsman, I can prove everything I write works as intended."
I think intended is a bit vague, but I like the idea. I would only
suggest something indicating a craftsmen's intentions are contentious
and well thought out.
How about:
As an aspiring craftsman, I can prove everything works as thoroughly
specified.
Dave Hoover
Right, but what happens when it's not thoroughly specified? Sometimes
what's intended is actually vague, and sometimes that's OK, and you're
writing the code that's necessary to get feedback about the customer's
intentions for the feature.
Raoul Duke
> specified.
imho i think this kind of approach is not going to work (for me at
least :-). i mean, come on, do you really think things are ever
thoroughly specified? i don't even know what on earth that means, or
how you'd prove the condition was met.
i'm not saying there aren't goals to shoot for, but i think the way
people are talking about them sounds way too pie in the sky /
unrealistic, which i think is a very fundamental problem with the
entire software culture. you've got Joe Crap Code on the one side and
Frank I Claim My Tests Prove It All Works -- Oh Wait, I Didn't Really
Understand That User Story Nuance Now That You Mention It.
sincerely,
-the extreme curmudgeon here, apologies.
Paul Pagel
client specification for a feature. Intention might actually be
closer to what i mean. Lets talk examples.
I sit down to implement some piece of code that calculates all the
prime numbers up to one hundred.
I write a tests that calculate the first five: 1,2, 3, 5, 7. By then,
I have an algorithm which will work. I check a few random ones (73,
37) to make sure.
I would then be able to say, these tests effectively prove the code
does what I intended it to do. I think that example scales up beyond
contrived math examples. If I write tests that prove my intentions, I
can be confident my code will work (even if sometimes i miss
something, that is the exception). The contentious part of the
statement is just to say that I think about the scenarios to test and
write a number of them, not just the happy path.
Esko Luontola
> specified.
http://thedailywtf.com/Comments/Stop_Reviewing_the_Code.aspx#86214
Heinrich Breedt
I'd suggest removing the implementation from the principle. "As an aspiring craftsman, I can prove everything I write works as intended."
That is the principle. And now we can go into detail and maybe say "Today, in [language], I believe that [process] with [tool] helps me achieve that in the simplist and cost effective way "
Heinrich
Raoul Duke
>> aspiring craftsman, I can prove everything I write works as intended."
>
> I like that.
it is interesting to me to see such a gulf between my reaction to
these, vs. responses from other people. i can hope it is a matter of
semantics -- that we all agree really and i'm just getting confused by
how things are phrased (but even in that case it is important to worry
about how it communicates to other people!), but i'm really worried
that somehow people think that they can "prove everything I write
works as intended."
are there any full time real QA/Test people who can weigh in on this?
i'm assuming they would have experience which would make them a little
leery of such phrasings?
(it isn't that i'm trying to kill this stuff, i'm trying to get it
refined to something realistic and thus valuable.)
sincerely.
Ralf Westphal
> And as Donald Knuth said: Beware of bugs in the above code; I have
> only proved it correct, not tried it.
conjunction with software to me seems utterly misleading.
leaving the so far irrelevant research on formal proofs aside there is
no proof of correctness for software.
software is not mathematics.
rather any software is a statement, a claim, or a thesis. and thus is
cannot be proven to be correct, but only falsified.
in that software development resembles physical or medical research.
neither a green unit test bar, nor a green bar with 100% code coverage
prove anything than "no bug has been hit".
in addition to that, no successful unit test guarantees the customer
will be satisfied with the software.
-ralf
Jason Gorman
On Mar 13, 6:54 am, Ralf Westphal <i...@ralfw.de> wrote:
> On Mar 12, 11:35 pm, Lance Walton <lancewal...@mac.com> wrote:
> leaving the so far irrelevant research on formal proofs aside there is
> no proof of correctness for software.
> software is not mathematics.
>
1. I thought that software is completely mathematical. A computer
program is a mathematical construct expressed in a formal symbolic
language, no?
2. Research into formal proofs - has it really been as irrelevenht as
you claim? And, yes, there are techniques that can prove that small,
simple programs completely satisfy a formal specification (though the
techniques haven't scaled very well). But they are in very limited use
on code that runs inside operational safety and mission-critical
systems. It's a niche, for sure, but please let's not casualyy sweep
it aside and all the efforts of all those great computer scientists to
at least try :-)
Jason Gorman
Casey Charlton
Jason Gorman
clarify this very important point.
My interpretation is that a craftsman has a line he/she does not
cross, even when the customer demands it. Similar to the example of
the patient telling the surgeon not to bother scrubbing up. Does the
surgeon explain the risks and then do as the patient demands? Have I
got that wrong?
Jason Gorman
http://www.parlezuml.com
> > >> At the risk of sounding snarky, works != craftmanship
>
> > --
> > Enrique Comba Riepenhausen
> > [@]: <eco...@gmail.com>
>
> - Show quoted text -
Enrique Comba Riepenhausen
> We shuld probably use some examples to illustrate and hopefully
> clarify this very important point.
>
> My interpretation is that a craftsman has a line he/she does not
> cross, even when the customer demands it. Similar to the example of
> the patient telling the surgeon not to bother scrubbing up. Does the
> surgeon explain the risks and then do as the patient demands? Have I
> got that wrong?
Casey Charlton
Enrique Comba Riepenhausen
Or it might be a case that you can work with the business. In my
experience my relationship with the business has been very beneficial
and collaborative.
The point is that if the business knows who you are they will have
expectations. If you don't talk to them and lower your personal bar on
any little request from the business you will only foster a behavior
from the business that does not really respect your professionalism
leading you to the situation you just mention...
Enrique
2009/3/13 Casey Charlton <ca...@goinsane.co.uk>:
Jason Gorman
compromise, you would compromise. That's not the same as quitting on
principle. In fact, it sounds like quite the opposite.
My question is: what is the software craftman's position? If we have
no line we will not cross, are we craftsmen?
Jason Gorman
Casey Charlton
Olof Bjarnason
> But this seems kind of fundamental. You said that if they asked you to
> compromise, you would compromise. That's not the same as quitting on
> principle. In fact, it sounds like quite the opposite.
>
> My question is: what is the software craftman's position? If we have
> no line we will not cross, are we craftsmen?
It is a give-and-take and customers do in fact listen if you tell them
what you think.
As Gojko made several real-life examples during his presentation at
SC2009@London, just asking the customer "why" and not blindly
accepting arguments such as "I want realtime video" which, taken
literally, whould require a whole new hardware/software arsenal.
Instead, when ask why do you want it, the customer explained what he
expected or imagined. The problem could be solved with pre-recorded
video-files that played when reaching certain spots in the fair (where
the software was to be run). Hope you get my meaning. (Gojko hope I
didn't retell this story all-too-distant from the original version..).
When the customer is my boss, I have seen black-white statements about
requirements. Even then it is possible to ask "why?" and get a decent
answer. Communication, communication..
Min blogg:
http://olofb.wordpress.com
[My blog, in Swedish]
Casey Charlton
Enrique Comba Riepenhausen
> But this seems kind of fundamental. You said that if they asked you to
> compromise, you would compromise. That's not the same as quitting on
> principle. In fact, it sounds like quite the opposite.
>
> My question is: what is the software craftman's position? If we have
> no line we will not cross, are we craftsmen?
can be experts in a field and industrial programmers, but not
craftsmen.
But that is only my humble opinion.
Enrique
Jason Gorman
same thing. But more importantly, in all mature professions,
professionals have lines they can't/won't cross, be it for ethical
reasons, for reasons of safety, and so on. A doctor might strongly
suggest you lose weight, for example, and explain the risks if you
don't. But if you're too overweight for an operation, the surgeons
won't operate. End of discussion! If the customer demands that the
architect leave out fire exits, the architect won't explain the risks
and then do as the customer says. If he did, he might be committing a
criminal offence.
Jas
Casey Charlton
Enrique Comba Riepenhausen
> professional") is to explain what you think is wrong with the
> position/decision ... and once you have done that, you get on with meeting
> the business need the way you have been asked to.
I don't believe that if you "get on meeting the business need the way
you have been asked to" you are having:
a) customer collaboration
b) productive partnerships
You are just accepting the control the customer is exercising over you
letting him/her dictate over your professionalism. Which again in my
case is not the way a craftsman works.
What seems to be misunderstood here is that there is nothing wrong
with being an expert or an industrial programmer. I mean the industry
of software development is full of cases like this, people accept it
and like to work in this environments. I have nothing against that,
everyone can choose his/her path. Software Craftsmanship breaks
through that though by raising the bar...
Enrique
Jason Gorman
Seriously, just... Wow!
Olof Bjarnason
>
> Wow!
>
> Seriously, just... Wow!
Yeah, agreed.
Look at it from the bright side - it is now empirically proven, that a
distinct line between SC and the s/w industry as a whole, exists.
James Martin
... we don't need zealots and fundamentalists in software. That ain't craftsmanship - that's the exact and total opposite. It's also unprofessional too if you want to split the two apart.
I think, as Uncle Bob so succinctly put it just this week, we /do/ in fact need zealots in software. I think the final paragraph of this article[1] describes one of the key differences between software craftsmen and software professionals:
"So here’s the bottom line. People who excel are, by definition, zealots. People who aren’t zealous, do not excel. So there’s nothing wrong with being a zealot; indeed, zeal is a very positive emotion. The trick to being a zealot is to be mindful that the day will eventually come when some other zealot from a different school of thought will code you into the ground. When that happens, you should thank him for showing you a better way."
2009/3/13 Jason Gorman <goo...@parlezuml.com>
I don't necessarily agree that "craftsman" and "professional" mean the
same thing. But more importantly, in all mature professions,
professionals have lines they can't/won't cross, be it for ethical
reasons, for reasons of safety, and so on. A doctor might strongly
suggest you lose weight, for example, and explain the risks if you
don't. But if you're too overweight for an operation, the surgeons
won't operate. End of discussion! If the customer demands that the
architect leave out fire exits, the architect won't explain the risks
and then do as the customer says. If he did, he might be committing a
criminal offence.
Jas
Thanks,
James.
[1] http://blog.objectmentor.com/articles/2009/03/10/lets-hear-it-for-the-zealots
Jason Gorman
But I hear Casey's argument being levelled at people a lot these days.
I think it's relativism. Everybody gets to be right, regardless of
where the evidence or the logic points.
I'm wondering now if, in exploring and defining these principles, we
should practice what we preach. Should there be acceptance criteria
for them? Should we use examples to build a shared understanding of
what we really mean (Casey's outburst suggests we might need to clear
up some ambiguities!)? Should we break the principles down and tackle
one a time, starting with the most important? Should we release many
drafts, incrementally adding and refining them based on objective
feedback as we go? Should we strive for the simplest set of principles
possible that will convey what wed mean by "software craftsmanship"?
It would be great if I could carry cards with my principles written on
the back as 3-5 ullet points :-)
Jason Gorman
Dave Hoover
> I would like to see if we can take a step back, look at the end goals
> we're setting out to achieve as craftsmen, and show that there are
> many routes to the kind of results we wish to achieve.
Jason, I have similar worries about SC = TDD++. Software
Craftsmanship is really *not* prescriptive of practice, technique, or
process. Looking at the end goals of what a Craftsmen should achieve
is a great approach to defining our principles. While methods like XP
tell us *how* to achieve our end goals for a project, Software
Craftsmanship sets the *standard* for our end goals for both projects
and careers. The finest-grained end goal of Software Craftsmanship is
a high-quality software system, a long-lived application that the
craftsman will maintain. The larger-grained end goals of Software
Craftsmanship are multi-year apprenticeships that produce future
community leaders, relationships between customers and craftsmen that
span careers, and ultimately, people growing themselves into master
craftsmen over the course of decades.
So +1 to a focus on end goals.
Best,
Dave Hoover
//obtiva: Agility applied. Software delivered.
Doug Bradbury
Dave Rooney
understand it, a case where you endlessly refine the code until you feel
it it's ready to be unleashed upon the world. Rather it's a case of
ensuring that it's as clean as possible to meet the immediate business need.
I like to refer back to Kent Beck's 4 rules for simple design. In
priority order, the code must:
1. Run all the tests
2. Contain no duplicate code
3. Express all the ideas the author wants to express
4. Minimize classes and methods
When those criteria are met, the code is likely good enough. Notice
that passing the tests and no duplication are the most important
criteria. You also have to realize that over time many small,
incremental refactorings will improve the overall design in a gradual
manner.
Now, back to the "industrial programmer". I'm willing to bet that most
if not all of them have never heard of Beck's rules. Furthermore, I'm
willing to bet that a majority of them don't even have automated tests,
so Rule #1 is impossible to start with!! That's part of the overall
education process that needs to take place. To be honest, I'd be much
happier raising the level of the industrial programmers, than trying to
create a relatively small group of craftsmen.
That's what will improve our industry as a whole, not some elite group
that knows better than everyone else.
--
Dave Rooney
Mayford Technologies
"Helping you become AGILE... to SURVIVE and THRIVE!"
http://www.mayford.ca
http://practicalagility.blogspot.com
Twitter: daverooneyca
Enrique Comba Riepenhausen wrote:
> 2009/3/12 Casey Charlton <ca...@goinsane.co.uk>:
>
>> At the risk of sounding like I'm in the wrong place... works > craftmanship
>>
>
> I must disagree with that for one simple reason (our first value in
> the manifesto):
>
> Not only working software, but also well-crafted software
>
>
>> If your priority is well written code, you almost certainly have a different
>> business goal from your employer. If you can achieve your business goals,
>> *and* have well written, maintainable, elegant, and just downright sexy code
>> too ... then all the better.
>>
>
> If someone is in the pursuit of what you just mention above, he/she
> would fall into the category of an 'industrial programer'.
>
> As most of us have mentioned before, there is nothing wrong about
> industrial programming, but I don't think that that is what we are
> looking for here...
>
> Cheers,
>
> Enrique
>
>
>> 2009/3/12 Curtis Cooley <curtis...@gmail.com>
Adewale Oshineye
programmers?' Please?
It's disrespectful and it makes us less influential as a movement.
People are less likely to be convinced of the merits of craftsmanship
if we call them names when they disagree with us.
The other downside of comparing ourselves to some strawman 'industrial
programmer' is that all we have to be is better than the strawman. My
standards are a little higher than that. I want us to be comparing
ourselves to the very best in our industry and seeking ways to surpass
them.
It's possible and perfectly acceptable for people to be highly
skilled, highly knowledgeable and still reject the tenets of software
craftsmanship. When we find such people we should try to learn from
them not attack them.
The danger for this movement is as Keith Braithwaite put it at XPDay
in London that we start saying "He is a cowboy. You are a hacker. I am
a craftsman." Let's focus on how we can be better rather than on
trying to change other people. If our results impress people then
they'll seek to emulate us. If they don't seek to emulate us then in a
competitive market we'll have a big advantage. I'm happy with either
outcome.
The very worst thing that could happen to the ideas of software
craftsmanship is if it becomes about hordes of consultants trying to
'transform' or 'enable' the unwilling masses at the behest of managers
who are merely latching on to the latest fad.
2009/3/13 Dave Rooney <davero...@gmail.com>:
Enrique Comba Riepenhausen
I was not aware that using the term "industrial programmer" could be
taken as offensive. If anyone in the list took that word as an offense
I am sorry for that, it was just used to make a difference between a
craftsman and a non craftsman.
I agree with you, Ade, that there are very talented and skilled people
that I would never call a craftsman. One of my friends, whom I
consider a wizard when it comes to programming, is not a craftsman at
all.
Enrique
2009/3/13 Adewale Oshineye <ade...@gmail.com>:
Curtis Cooley
> I'm wondering now if, in exploring and defining these principles, we
> should practice what we preach. Should there be acceptance criteria
> for them? Should we use examples to build a shared understanding of
> what we really mean (Casey's outburst suggests we might need to clear
> up some ambiguities!)? Should we break the principles down and tackle
> one a time, starting with the most important? Should we release many
> drafts, incrementally adding and refining them based on objective
> feedback as we go? Should we strive for the simplest set of principles
> possible that will convey what wed mean by "software craftsmanship"?
> It would be great if I could carry cards with my principles written on
> the back as 3-5 ullet points :-)
>
This is exactly what we need to do, or we will never have these
principles. We've gotten a lot of input from a lot of people, but I
feel we are approaching the endless/needless refactoring phase and
risk not delivering the requested feature.
We need to do the simplest thing that could possibly work, release it,
then iterate over it. If we can come up with acceptance criteria
first, even better, but it's time to stop refactoring and release the
feature.
--
Curtis Cooley
curtis...@gmail.com
===============
Once a programmer had a problem. He thought he could solve it with a
regular expression. Now he has two problems.
Enrique Comba Riepenhausen
> Now, back to the "industrial programmer". I'm willing to bet that most
> if not all of them have never heard of Beck's rules. Furthermore, I'm
> willing to bet that a majority of them don't even have automated tests,
> so Rule #1 is impossible to start with!! That's part of the overall
> education process that needs to take place. To be honest, I'd be much
> happier raising the level of the industrial programmers, than trying to
> create a relatively small group of craftsmen.
With "industrial programmer" we don't refer to a bad programmer
without any sense of coding nor good practices. I know many very good
programers that I would not categorize as craftsmen, hell, some of
them are orders of magnitude better coding than I am.
I must agree with Ade here, we should really stop using the term as it
seems that some people don't really understand what we meant with it
(maybe we didn't explain ourselves well enough) and use it in a
derogatory way.
Enrique
Tim Ottinger
> On Wed, Mar 11, 2009 at 11:59 PM, Torbjörn Gyllebring
> <torbjorn....@gmail.com> wrote:
>> 2: Can code responsibly be written without TDD, here meaning:
>> * Never write production code without a failing test.
>> * Never write a test without a essential need.
>> * Never identify a need without a customer.
>> * Merciless refactoring.
>> * Follow the Feathers commandments on what is a unit test.
>>
>> I would say yes, TDD is _how_ many of us choose to developsoftware but
>> arguing that it's "the only way" is somewhat silly.
We use the most powerful and reliable techniques we know , and continue
to look for better ways.
Tim Ottinger
> At the risk of sounding like I'm in the wrong place... works >
>
Wrong question, excluded middle, etc.
Works but is a piece of crap < Works with well-crafted code.
Let's just put that one to bed. There is no reason to trot out "mine is
better
that yours because it works" crap. As craftsmen, working is obviously the
goal. But that is too small a goal for us. We want it to obviously
work, and
work well, and survive ongoing maintenance and enhancement is good style.
Works is too small for craftsmen. We would like some adjectives and
adverbs on that.
Tim Ottinger
> The responsibility of being a craftsman (though I prefer the term "a
> professional") is to explain what you think is wrong with the
> position/decision ... and once you have done that, you get on with
> meeting the business need the way you have been asked to.
>
> Someone who is not a craftsman/professional will just do it without
> explaining the issues they see ahead.
>
> Similarly, as a business owner I would view someone who said they
> would not do X due to their principles, after I have told them I
> understand their position, but would now like them to do what I have
> asked the way I have asked to be totally unprofessional (not worthy of
> being a craftsman), and would expect them to quit or be fired.
>
and ethics.
Be aware that it's so.
If it's a matter of doing something we don't like much, a professional
does the job. We don't
have to have our heart fully in it. But it is clearly unprofessional to
ask anyone to compromise
their convictions and ethics.
Standards is the conversation we should be having. That's a negotiable
space.
Denny Abraham
itself is more difficult since then you'd either have to assume or
prove several things about the language first. That may be more
tedious and difficult than your algorithmic proof to begin with.
And about 'knowing' your software works, here's a link via Michael
Feathers on that very subject:
http://twitter.com/mfeathers/status/1193954394
Outside of testing against a specification of the function of your
code, claiming that you 'know' it works is an elusive proposition.
On Fri, Mar 13, 2009 at 2:52 AM, Jason Gorman <goo...@parlezuml.com> wrote:
>
>
>
> On Mar 13, 6:54 am, Ralf Westphal <i...@ralfw.de> wrote:
>> On Mar 12, 11:35 pm, Lance Walton <lancewal...@mac.com> wrote:
>> leaving the so far irrelevant research on formal proofs aside there is
>> no proof of correctness for software.
>> software is not mathematics.
>>
>
> I think there are tow claims here that need to be qualified:
>
> 1. I thought that software is completely mathematical. A computer
> program is a mathematical construct expressed in a formal symbolic
> language, no?
> 2. Research into formal proofs - has it really been as irrelevenht as
> you claim? And, yes, there are techniques that can prove that small,
> simple programs completely satisfy a formal specification (though the
> techniques haven't scaled very well). But they are in very limited use
> on code that runs inside operational safety and mission-critical
> systems. It's a niche, for sure, but please let's not casualyy sweep
> it aside and all the efforts of all those great computer scientists to
> at least try :-)
>
> Jason Gorman
> >
>
Denny Abraham
concrete betterment of billions. If we are to call non-craftsman
something, I'd rather it be something that doesn't implicitly label
craftsmanship as antiquated or cost-ineffective.
Michael Wilson
At the risk of being mind numbingly pedantic:
Industry has indeed supplanted craftsmanship, but it has always been the
product of craftsmanship. This is still an exceptionally young field.
Let's not endeavor to skip the important bit.
Dave Rooney
(well at least in the Toyota vs. GM sense). That said, we do indeed
need more craftsmanship, or at least better definitions of it, before we
settle into an industrial mode.
I also agree that our industry is quite young, and I've said that quite
often. We probably weren't very good a building bridges 60-70 years
after we first started, although most of them "worked". ;)
Michael Wilson wrote:
> At the risk of being mind numbingly pedantic:
>
> Industry has indeed supplanted craftsmanship, but it has always been the
> product of craftsmanship. This is still an exceptionally young field.
> Let's not endeavor to skip the important bit.
>
--
David Stanek
>
> Folks, don't misinterpret "well-crafted code". It's not, at least as I
> understand it, a case where you endlessly refine the code until you feel
> it it's ready to be unleashed upon the world. Rather it's a case of
> ensuring that it's as clean as possible to meet the immediate business need.
>
> I like to refer back to Kent Beck's 4 rules for simple design. In
> priority order, the code must:
>
> 1. Run all the tests
> 2. Contain no duplicate code
> 3. Express all the ideas the author wants to express
> 4. Minimize classes and methods
>
In my mind a craftsman should strive to meet those rules. Keep the
principles in mind while delivering customer value. But sometimes it
is not that easy with a legacy application.
The problem I have is that I can't always factor out duplication or
change designs that should be changed. We as a company are not in a
position to test the entire set of applications we produce in an
automated way. I'm not saying we shouldn't be in that position. We are
heading slowly in that direction, but we are not there yet. Instead we
strategically figure out what needs to be changed and then
systematically implement.
Does this make us or anyone working on legacy software non-craftsmen?
--
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
Mark Levison
On Fri, Mar 13, 2009 at 1:31 PM, David Stanek <dst...@dstanek.com> wrote:
>
> On Fri, Mar 13, 2009 at 9:09 AM, Dave Rooney <davero...@gmail.com> wrote:
>>
>> Folks, don't misinterpret "well-crafted code". It's not, at least as I
>> understand it, a case where you endlessly refine the code until you feel
>> it it's ready to be unleashed upon the world. Rather it's a case of
>> ensuring that it's as clean as possible to meet the immediate business need.
>>
>> I like to refer back to Kent Beck's 4 rules for simple design. In
>> priority order, the code must:
>>
>> 1. Run all the tests
>> 2. Contain no duplicate code
>> 3. Express all the ideas the author wants to express
>> 4. Minimize classes and methods
>>
> change designs that should be changed. We as a company are not in a
> position to test the entire set of applications we produce in an
> automated way. I'm not saying we shouldn't be in that position. We are
> heading slowly in that direction, but we are not there yet. Instead we
> strategically figure out what needs to be changed and then
> systematically implement.
>
> Does this make us or anyone working on legacy software non-craftsmen?
Mark
Blog: http://www.notesfromatooluser.com/
Recent Entries: Agile/Scrum Smells: http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
Agile Games for Making Retrospectives Interesting: http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
Curtis Cooley
>
> I agree - our ultimate goal shouldn't be craftsmanship, but industry
> (well at least in the Toyota vs. GM sense). That said, we do indeed
> need more craftsmanship, or at least better definitions of it, before we
> settle into an industrial mode.
>
> I also agree that our industry is quite young, and I've said that quite
> often. We probably weren't very good a building bridges 60-70 years
> after we first started, although most of them "worked". ;)
>
http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge_(1940)
Lance Walton
Ralf, I'm pretty sure that Knuth was doing one or both of two things
when he made this statement:
1. Making a joke
2. Pointing to the fact that we can guarantee correctness in the sense
of type safety etc., but not in the sense that the program does what
some user wants. The former will continue to improve with time, and
some of it may even be adopted into the mainstream. The latter
requires technical skills, communication skills, analytical and
interrogative skills, craft and a touch of magic.
Regards,
Lance
Esko Luontola
codebase cleaner than you found it.
http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6
That would also apply to legacy code, where we can not save the world
immediately, but we can improve it little by little.
Robert Martin
Mark Levison
Christian Vest Hansen
>
>
> On 3/14/09, Esko Luontola <esko.l...@gmail.com> wrote:
>>
>> A craftsman would follow the boy scout rule: Leave the campground/
>> codebase cleaner than you found it.
>> http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6
>>
>> That would also apply to legacy code, where we can not save the world
>> immediately, but we can improve it little by little.
>
>
> Too me at least this the key and perhaps the minimum.
>
> I would add perhaps: When broken windows are found a craftsman always fixes
> them (or at least starts to fix them).
are usualy happened upon on the way to something else. Some code bases
have so many broken windows that, if I were fix each and every one
upon first encounter, I would quickly find myself in the middle of a
huge refactoring effort and never be done with my original task.
Merely beginning to fixing is not enough. Half a fix is not a fix. An
improvement can in some cases be scaled down, but I'm wary to commit
code that is in the midst of a restructuring - say I forget to
complete the restructuring and leave it in pieces.
>
> Mark
>>
>> Blog: http://www.notesfromatooluser.com/
>> Recent Entries: Agile/Scrum
>> Smells: http://www.notesfromatooluser.com/2008/06/agilescrum-smells.html
>> Agile Games for Making Retrospectives Interesting:
>> http://www.notesfromatooluser.com/2008/10/agile-games-for-making-retrospectives-interesting.html
>
> >
>
Venlig hilsen / Kind regards,
Christian Vest Hansen.
Raoul Duke
> are usualy happened upon on the way to something else. Some code bases
> have so many broken windows that, if I were fix each and every one
> upon first encounter, I would quickly find myself in the middle of a
> huge refactoring effort and never be done with my original task.
furthermore, there's giving people fish, and teaching them how to fish
for themselves. if you don't fix the people + process that broke the
windows in the first place...
which can be an uphill battle, of course.
sincerely.
Mark Levison
I disagree (with the wording, at least). I find that broken windows
>
> Too me at least this the key and perhaps the minimum.
>
> I would add perhaps: When broken windows are found a craftsman always fixes
> them (or at least starts to fix them).
are usualy happened upon on the way to something else. Some code bases
have so many broken windows that, if I were fix each and every one
upon first encounter, I would quickly find myself in the middle of a
huge refactoring effort and never be done with my original task.
Merely beginning to fixing is not enough. Half a fix is not a fix. An
improvement can in some cases be scaled down, but I'm wary to commit
code that is in the midst of a restructuring - say I forget to
complete the restructuring and leave it in pieces.
I'm referring to doing a rename or extract method or some other small refactoring. You may not have solved the entire problem but you made one small local improvement. So I suggest that beginning and checking in is much better than not starting at all because you didn't have time to finish. Even craftsman have time pressure - the difference is in how they deal with it.
Cheers
Mark