Quintessence: The fifth element for the Agile Manifesto

Dave Hoover 17 minutes later:

• • Bob, I propose “Craftsmanship over Heroics”. Full explanation here

Cory Foy 19 minutes later:

• • Was just thinking about that last night during a presentation I gave. It’s a shame because “Craftsmanship over Crap” is so clear.

  • But perhaps, “Craftsmanship over Production” – we value quality, clean code over just cranking it out. Much like I prefer a solid wood desk over a particle board one.

David Dossot 25 minutes later:

• • “Craftsmanship over Brinksmanship”

  • For the good work and also because there can be value in brinksmanship, though it is risky in software.

Hank Roark 28 minutes later:

• • Some possible alternatives ‘Quality over Efficiency’ or ‘Craftsmanship of Efficiency’.

  • Probably influenced by Cooper’s keynote.

Mike Bria 33 minutes later:

• • Now, this one is not a “Blathering”. I can’t say if whether or not I favor the idea of adding another value statement – but that aside, this would be the one that is needed. Believe it or not, I’ve made statements verbally like this for awhile, except I have thought of it as ‘Artistry over Engineering’.

  • I’m sold on Craftsmanship, that’ s more accurate than Artistry. (Although I do consider what we do, when done well, an ‘art’).

  • The thing about Engineering versus Execution – it (unfortunately) hits more on a commonly applied, although ever-so misplaced label of our pre-agile days. My title for many years was a “Software Engineer” of some flavor or another. I think that a focus of Engineering, traditionally, is the execution of (often known) steps with the focus on assembly; construction; “making something work”. The art of the steps, the implementation – the craft – takes a backseat, if present at all.

  • Anyway, now I’m blathering. I guess I’m throwing “Craftsmanship over Engineering” out there.

  • Maybe that’s not what you had in mind, who knows. Either way, I’m excited to see where this goes – it’s overdue.

I think execution is good about 1 hour later:

• • I toyed with convenience, expediency, efficiency, etc., but I think frankly execution is probably the best.

  • I don’t think efficiency is good, because I actually think that craftsmanship is more efficient, optimizing on the whole. I do kind of like mike’s craftsmanship over engineering, but I’m waffling.

Christian Gruber about 1 hour later:

• • Ugh… I can’t read. The above comment with the subject instead of the name is mine. :(

Hamlet D'Arcy about 1 hour later:

• • I love it because it perfectly sums up the challenges I’ve personally faced at several jobs over the years. Sometimes the alternative I battled was heroics, sometimes efficiency. But Execution seems to be the super-group for all the other suggestions. But is this part of the /Agile/ manifesto? Or is this the first principle in the as-yet-uncreated Software Engineer manifesto?

Nathan Henkel about 1 hour later:

• • To me “execution” sounds like “working software” (the aim of development is working software, so that is what we have when we’ve “executed”), which results in a ternary relationship:

  • Well-crafted software > (merely) working software > comprehensive documentation

  • Maybe that’s right, but I think that’s really what’s being proposed here

Samuel A. Falvo II about 2 hours later:

• • To value craftsmanship, you must also have a craft. All these years, the software development industry has been trying to position itself as an engineering discipline. Time and time again, however, it seems to have failed in this otherwise desirable endeavor.

  • For many, many years, I’ve felt strongly that programming is best taught as a craft, where a junior coder is taught under the auspices of a more senior coder. As I’m a student of aikido, I feel that a dojo-like environment is best here, as the 18 different ranks offers greater and more frequent feedback to the candidate than the simple 3-tiered European model of apprentice, journeyman, and master.

  • For example, total neophytes could be admitted as kyukyu (9th kyu rank), and proceed up the ranks until they achieve their blackbelt in coding (shodan, or 1st black belt), at which point they are finally considered students of the craft. Ranks beyond shodan go all the way up to kyudan (9th degree black belt). At rokudan (6th degree), one may be considered a “shihan”, at which point, you’re basically free to form your own school of thought and practice. People like Donald Knuth and Niklaus Wirth would be awarded 9-dan ranks, as they’re the eldest and most knowledgable of their respective schools of thought, while people like me are probably 2-dan or 3-dan at best, struggling to continually self-improve and acquire knowledge from different masters as I form my own understanding.

  • The ranking system is measured objectively (“I don’t care if you’ve been here 3 months or 3 years; if you can’t fall right, you’re not getting the next belt.”), not competitively, as tests are in western colleges. For this reason, perhaps a valid value might be expressed as, “Craftsmanship over degrees.”

Bill Schofield about 2 hours later:

• • “Important Work over Urgent Work”

  • This feels very related to the “Important versus Urgent” decision making problems that most people have.

  • While we know it is important to test, refactoring, and continuously design our code, it feels very URGENT to get this current feature done TODAY.

  • Most of the Crap I have encountered came very clearly from someone deferring important work for urgent work.

Anthony Bailey about 3 hours later:

• • Maybe you shouldn’t limit yourself to single words – the other elements don’t. For example, “Clean and well-crafted solutions over those that merely work.”

  • (There’s probably a better phrasing that makes it even more clear we remain YAGNI about premature design and architecture, just not about the code quality.)

William Pietri about 3 hours later:

• • How about “craftsmanship over quantity”? That although we do value the raw quantity of software made, we value well-crafted software more.

  • Is it time for Agile Manifesto 2.0? As long as we’re looking at changing it (and after 7 years, changing it’s not entirely crazy) I’ve got some other suggestions.

Adam Keys about 3 hours later:

• • Good execution is something I highly value. So how about “Craftmanship over toil”?

Ben Monro about 5 hours later:

• • Wait, so Execution was a synonym for Crap?

Ben Monro about 5 hours later:

• • Wait, so Execution was a synonym for Crap?

  • what the heck kind of thesaurus was that?

zac about 6 hours later:

• • Maintainability over Immediacy?

Peter Wood about 15 hours later:

• • Tom de Marco, in Peopleware – Productive Projects and Teams says:

    • Quality, far beyond that required by the end user, is a means to higher productivity.

  • I think this means that allowing developers to set the expected quality by their own standards will make them happier and better invested in their work. It allows them to practice their craft.

  • Maybe:

    • Allowing personal quality expectations over just meeting customer’s expectations.

Patrick Welsh about 18 hours later:

• • This one is tricky. The template we seem to want to preserve is “We prefer [less-obviously-valuable thing] over [traditionally-preferred thing].” No-one claims to prefer crap, though one could argue that nearly all “documentation” falls into that category.

  • It’s not that we would ever prefer well-crafted code over the delivery of business value. It’s that we believe that you can only deliver business value at least cost IFF (if and only if) it is well-crafted. Indeed, we would claim that the higher the level of craft, the lower its long-term cost, by definition.

  • It’s not execution I abhor, since execution delivers business value. It’s sloppy, expedient, emergency execution that I abhor. It’s Hacking that I abhor.

  • Hacking may deliver short-term business value, but only at unaffordable interest rates. Craftsmanship, aside from any aesthetic consideration, delivers least Total Cost of Ownership, and highest Return On Investment. Hacking is the Faustian Bargain.

  • I wonder about this phrase: “We prefer Craftsmanship over Hacking.”

Declan Whelan about 20 hours later:

• • Craftsmanship is a great word. It also nicely encapsulates Brian Marick’s proposed extensions to agile values: skill, discipline, ease and joy.

  • As to the balancing clause of the statement; I struggle with “execution” because it does not seem to me to be a competing force to craftsmanship. My experience is that the impediments to craftsmanship are often inertia, ignorance, laziness and complacency rather than an overt focus on execution. Perhaps what these impediments have in common are some form of resistance to change which manifests itself as repeatability.

  • So how about “Craftsmanship over repeatability”.

Curtis Cooley about 21 hours later:

• • How about Craftsmanship over Construction to link to the work of Steve McConnell. I just read a blog at Java World where the guy proposes Hungarian notation so readers of code can tell fields, from method arguments, from local variables. Yes, Hungarian notation in the 21st Century! I though those kinds of things were behind us.

  • http://www.javaworld.com/javaworld/jw-07-2008/jw-07-harmful-idioms.html

Thomas Nilsson 1 day later:

• • I am not at all sure that I like adding your suggestion as a fifth element. I think that by examining what we mean by “Working Software” it is not needed.

  • “Working Software” does not mean “it’s done, since it is running”. To me it means that it actually works, in the same way that it fullfills all of its purposes, “fitness to purpose” if you will.

  • This would mean that not only does it function, it also gives a positive user experience, is fit for future change, has quality enough to not surprise and so on. I strongly believe that the term quality do include all dimensions of such fitness. Usually the Q-word is used in more restricted meanings, which takes away from its value.

  • Again, by viewing “Working Software” to include this dimension we don’t need any specific craftmanship element.

  • If anything, I think that David Anderssons suggestion of a fifth element has more merits. He proposed a fifth element focusing on Continous Improvement, which I think is at the heart of Agile, and missing in the Manifesto.

Bradley Harris 1 day later:

• • I really like the idea. Like some others above, I also wish that it could stay “Craftsmanship over Crap” because that really captures the point better than any of the other suggestions.

  • I think that “Craftsmanship over Execution” is just too open to misinterpretation. It can easily be read to mean that we value software that is well crafted even if it doesn’t do anything useful.

  • My suggestion would be “Craftsmanship over Yield”.

Dmitri Zimin(e) 1 day later:

• • Interesting.

  • How about reverse: “Execution over craftsmanship”. The software development in real world has always been the art of unpleasent compromises. They are nessessery to ship working software, see principle #1.

  • We don’t like this reality, it’s another story. “Craftsmanship over execution” is great to those who can afford estimations of “I’ll see you when I am done” (there are quite a few!)

  • To tribute repect to craftsmanship, I’d better rephrase it further to “Execution over goldplating”. But it is cheap for adding to the manifesto.

Brian Marick 1 day later:

• • I like Anthony Bailey’s.

  • It aligns with the results of the technical debt conference, where people started talking about good code as an asset. Bad code produces value mostly by being executed. Good code produces that value, plus it’s a resource you can easily use to produce still more value.

  • “Code crafted to expand business possibilities over code that merely works”?

Aaron 3 days later:

• • I prefer “craftsmanship over scrabble “

Domien Holthof 4 days later:

• • What about “wisdom over knowledge”.

  • Of course, knowledge is an essential aspect of anyone who is involved in software developement and the more you have of it the better. But in the end, everyone should go beyond the knowledge and have it transformed into wisdom. Maybe it’s synonymous for “gut feeling”, but then you see that in any craft. The really good craftsmen just “seem” to know which are the right decissions to make. But of course that wisdom is something that has evolved out of practicing (and at least as often mispracticing) lots of knowledge.

  • On the other hand, I’ve already encountered numerous people in the business who are bloated with knowledge, but lack the wisdom to take the right decisions based on that knowledge.

JV 6 days later:

• • Craftsmanship over Crap. It’s just perfect!

Charlie Martin 6 days later:

• • Bob, I think there’s an underlying problem: what is this “craftsmanship” of which you speak so highly? As an old formal methodist, I might be tempted to suggest a rigorous proof of correctness is necessary. As an objects guy, I might want to demand a well-documented domain model. As an admirer of the Parnas/Clements et al A-6 methodology, I might want to argue for a mechanically-generated multiple cross index. Or code structured around loci of probable change. As a mathematician, I might demand “elegance”.

  • But then as an Agile guy, I might claim all these to be more complicated than what might possibly have worked.

Manoj Waikar 6 days later:

• • I think “Craftsmanship over code” would be great too, because few people write well-crafted code; most just code without any meaning. Obviously that code works, but that is the only attribute of it, nothing else.

Michael Sahota 7 days later:

• • I don’t like “Execution” since there is good execution and bad. This is too water-ed down to be useful.

  • I actually think “Crap” is good to use. Many business (not developers) do value crap.

  • Perhaps “Maintainable Code” over “Unmaintainable Code” but this is weaker.

Chet Barber 7 days later:

• • How about “Quality over Quantity” because craftmanship usually connotes quality. This is fairly generic but I think it fits into the “new focus” versus “traditional valued” metric comparison. There is need and desire to generate functionality just that when doing so we value quality over SLOC. The idea of quality also applies to the whole development process (i.e. retrospectives) and so spending time to do these activities imcreases the quality of the process while perhaps some time is “wasted” doing this versus “coding” or “real” work.

  • If you just really like the word “craftmanship” then I like what one former commenter had “Craftmanship versus Expediency”. Doing it right versus just getting it done as quickly as possible with no thought to the long-term consequences.

Philip Schwarz 7 days later:

• • @Charlie Martin

  • You asked Bob ‘what is this craftsmanship of which you speak so highly?’

  • The way I read his post, Bob is saying that craftmanship means behaving professionally and writing clean code.

  • To see what he means by clean code, and to contrast it with the code produced by mere ‘execution’, see the following excerpt from his ‘Clean Code’ paper:

  • ##################################################### ...I am not expecting you to be able to write clean and elegant programs in one pass. If we have learned anything over the last couple of decades, it is that programming is a craft, more than it is a science. To write clean code, you must first write dirty code; and then clean it.

  • This should not be a surprise to you. We learned this truth in grade school when our teachers tried (usually in vain) to get us to write rough drafts of our compositions. The process, they told us, was that we should write a rough draft, then a second draft, then N subsequent drafts until we had our final version. Writing clean compositions, they tried to tell us, is a matter of successive refinement.

  • Most freshman programmers (like most gradeshoolers) don’t follow this advice particularly well. They believe that the primary goal is to get the program WORKING. Once it’s WORKING they move on to the next task, leaving the WORKING program in whatever state they finally got it to work. Most seasoned programmers know that this isPROFESSIONAL SUICIDE. #####################################################

  • I relate this simple’execution’, or professional suicide, to Ward Cunningham’snotion that ‘Shipping first time code is like going into debt’

  • I also relate execution, and clean code to ‘make it run’ and ‘make it right’ respectively in the following programming mantra: ‘Make it run, make it right, make it fast’.

Ilja Preuß 8 days later:

• • “Sustainability over Immediacy”?

R.J. Osborne 8 days later:

• • Crap is a byproduct, not a valued component. This conflicts with contracts, tools and the like. It’s the “Just make it work” philosophy that yields the crap. I label that “expedience” as a motivating factor from a stakeholder’s perspective.

  • Expedience does have a value. Rapid feedback depends on rapid development. Testing, refactoring, succinct domain modeling- that all takes time to do right—especially when integrating a new concept into an existing codebase.

  • Sadly, a customer usually just wants something expedient with the hidden trade-off that it’s just plain crappy.

Tim Ottinger 8 days later:

• • How about “code ethics over code expedience” ?

Jason 8 days later:

• • I think craftmanship is implied with delivering quality, bug-free and potentially shippable software.

  • Having to specifically say ‘craftmanship over crap’ seems very anti-agile to me. No developer should be churning out crap for the sake of getting something ‘done’

Gurkan 12 days later:

• • How is “Cratmanship over Supermanship”?

Brad Appleton 19 days later:

• • I have a saying I’ve been using for about 5 years now: “palpable progress over mercenary motion” which perhaps gets at what you mean by “execution” but probably doesnt convey “craftsmanship” well enough.

  • Another is a personal motto Ive been saying for about 10 years now. In the past Ive had people telling me I really shouldnt give a crap so much, and its “just work” as an excuse for producing crap. My response was: I do give a crap; I don’t take any crap, and I refuse to produce crap!” and they had no right to tell me I should feel otherwise!

Clinton 22 days later:

• • In software, as in old world craftsmanship, experience and problem complexity largely determine whether the developer can craft ’’pretty’’ code on the first round. Patrick’s ``Craftsmanship over Hacking’’ is compelling.

  • Philip has a good mantra for how to get from one state to the other ``make it run. make it right. make it fast.’’ My variant is ``first make it work then make it pretty.’‘

Philip Schwarz 25 days later:

• • @Clinton

  • You said: Philip has a good mantra for how to get from one state to the other ``make it run. make it right. make it fast.’’

  • Thanks Clinton….it is good, I got it from Kent Beck. I found it in Jeff Langr’sJava Style – Patterns for Implementation (a good book). I cannot find where Beck wrote it.

  • There is some discussion of it here: Make It Work Make It Right Make It Fast.

Philip Schwarz 25 days later:

• • @Clinton

  • You said: “first make it work then make it pretty”.

  • Since you value Beck’s mantra’, it is likely that you are using ‘pretty’ to mean ‘right’/’good’/’clean’. If so, then, on the one hand I find your usage of ‘pretty’, acceptable because ‘pretty’ is the antonym of ‘ugly’, and I am quite comfortable referring to bad code as ‘ugly’. But on the other hand I object to it because when I read ‘first make it work then make it pretty’ I can’t help thinking that ‘pretty’ is being used in a pejorative sense and that you really mean ‘I favour function (making it work) over form (making it pretty/beautiful) because the latter has less/little/no value’.

  • If however you are using ‘pretty’ to mean ‘pleasing to the senses, but of little/no utilitarian value’, then maybe you disagree that there is a third state between ‘functionally correct’, and ‘fast’, where aesthetics matter: ‘well written’.

  • In Smalltalk Best Practice Patterns, Kent Beck is not afraid of using the word‘style’: ‘Good programming style is one of those things that everyone knows when they see it but is very hard to articulate precisely’. The book teaches us patterns for writing code with good style.

  • In Essential Java Style – Patterns for Implementation, Jeff Langr uses Beck’s patterns (adding some of his own) to teach us how to write clean code. While he uses the term ‘style’ in the title, he says that ‘Style is an imprecise word: the word style connotes flash, panache, coolness…[which does not] accurately describe the goal of this book, which is why it has a subtitle: ‘Implementation patterns’.

  • In his latest book, Implementation Patterns, Beck has a compelling definition of programming style: ‘These three elements – values, principles, and patterns – form a balanced expression of a style of development. The patterns describe what to do. The values provide motivation. The principles help translate motive into action. ... The result is a style of development, not the style of development. Different values and different principles will lead to different styles.

  • In Agile Software Development – Principles, Patterns, and Practices, Uncle Bob is not afraid to talk about beauty: ‘What does it take to make a module easy to read and easy to change? Much of this book is dedicated to principles and patterns whose primary goal is to help you create modules that are flexible and adaptable. But it takes something more than just principles and patterns to make a module that is easy to read and change. It takes attention. It takes discipline. It takes a passion for creating beauty.’

  • Making code right/clean/beautiful/pretty(?) is very important.

  • In the preface to Implementation Patterns, Kent Beck says the following: ‘This book is built on a rather fragile premise: that good code matters. I have seen too much ugly code make too much money to believe that quality of code is either necessary or sufficient for commercial success or widespread use.’ But then tells us that ‘writing good code is potentially profitable and that ‘coding well is satisfying, both the act itself and the knowledge that others will be able to understand, appreciate, use and extend my work’.

  • In his new book, Clean Code, Uncle Bob says that when he read the preface he thought: I disagree! I think the premise is one of the most robust, supported, and overloaded of all the premises in our craft (and I think Kent knows it). We know good code matters because we’ve had to deal for so long with its lack.

taleswapper 25 days later:

• • I’m wondering if it isn’t a little more abstract/emotional that craftsmanship? It seems to me that the craftsmanship thing is about taking responsibility for the end product, not letting excuses (including the customer’s desire to affect schedule or whatever) so that we have tangible responsibility for the resulting output. There ought to be something about ownership/obligation with the product for its lifetime.

  • Maybe being a part of the collaborative team is about honor over haste? Pride over precipitateness.

Alan Cooper 28 days later:

• • First, I’d like to wholeheartedly endorse both Uncle Bob’s emphasis on craftsmanship and his assertion that there’s a subtle missing piece in the Agile Manifesto. As he says, “Craftsmanship over crap” is effective histrionics but may not be sufficiently clear for a constitutional amendment, so to speak.

  • Creating quality code is a primary force behind all agile programming, so equating “craftsmanship” with “quality code” seems redundant. What’s more, it still doesn’t really scratch the itch here. I believe that what Uncle Bob means by “crap” has more to do with the end result of what we create than it does with the code itself.

  • As we have all learned the hard way, if we simply give our customers what they ask for, it will suck, even if the code is clean. As I see it, the strongest, most revolutionary, and most compelling aspect of agile is its emphasis on creating a quality product, rather than just quality code. A quality product is one that pleases customers and users, while a quality program is one that merely implements functionality.

  • The craftsman understands that his primary, overarching goal is to create a very happy, very satisfied user. He also knows that pleasing users is extremely satisfying for the craftsman as well. It is his responsibility as a craftsman to assure that the customer gets what will make him happy and not just what he asks for. After all, being the user of complex software doesn’t imply possession of any skills or aptitude for designing that software any more than it implies skills for coding it.

  • To the widespread frustration and disappointment of software users, they are more often than not given feature-packed software that, while it may be composed of clean code, is ill-behaved, hard to use and understand, and it doesn’t satisfy them. Such code may be created by skilled programmers, but not by responsible craftsmen. Such code is crap.

  • So I would propose that the fifth statement added to the Agile Manifesto should read like this: “Responsible craftsmanship over features and functions.” While there is value in the latter, we value the former more.

  • Part of the well-tempered agile programmer’s craft is knowing that his end goal is generating a fierce customer loyalty to his product by imbuing it with good and appropriate behavior, without compromising the more esoteric needs of his own technical specialty. A product becomes desirable because it behaves well, while its functionality is merely a hygienic necessity. That is, its presence conveys little added value, while its absence is damaging.

  • Craftsmen, almost by definition, don’t stop at the minimum requirements, but strive ever to excel, to super-please, and to create highly desirable, human-scale objects. Yes, they take pride in the perfection of their hand-cut, blind dovetail joints that the user will never even see, but they know that their beautiful joinery is only a means to a bigger end.

John Boyes about 1 month later:

• • Bob, I’d like to propose “Craftsmen over Journeymen”.

  • We do value Journeymen – after all we all start out as Journeymen – but we value Craftsmen more.

  • Some programmers stay as Journeymen their whole lives – and we definitely value Craftsmen more.

  • Anyone else agree?

Chris Gough 2 months later:

• • Seems like a lot of discussion about choosing a word for “not-craftsmanship”.

  • Why not just append ”... and craftsmanship matters”?

  • Is the “foo over bar” pattern really important?

John Vars 3 months later:

• • “Craftmanship over Quick”. Well-crafted solutions tend to take a little longer initially but require little rework before they are completely accepted by the client. Quick coding can satisfy an initial requirement to deliver something fast but the longterm cost of maintaining it and your relationship with your clients will not.

Brandon Joyce 3 months later:

• • Craftmanship over Crap is perfect. Don’t change it. Love it.

Alistair Cockburn 3 months later:

• • Stay with “Craftsmanship over Crap”

  • Screw the manifesto – you’re making a point, and you make it better with an alliterative fighting line instead of balanced woo-woo political politeness

  • :-)

  • Alistair

  • p.s. thanks for making me sit there and help write a manifesto. You were right and I was wrong.

Esko Luontola 3 months later:

• • My proposal is:

  • “Craftsmanship and quality over going into production”

  • This explains the term “craftsmanship” by linking it closely to quality. Also, the term “execution” is too vague IMHO, so I replaced it with a more explicit “going into production”.

  • Here quality refers to both code quality and product quality (it should be said explicitly in the manifesto’s principles). The code must be clean and of highest quality to allow maintainability. The product must be what fills the needs of the users, which is not necessarily what the client initially wants and asks for (what the client thinks he needs). (I face this often when doing user interface design/requirements analysis – the client’s don’t always know what’s best for them, but we know how to dig the necessary information out of the users and design a product which fills their needs as well as possible.)

  • Going into production is important and is already part of the manifesto as “working software”, but craftsmanship and quality are even more important. You don’t want to deploy crap into production.

Eric Farr 4 months later:

• • I like Craftsmanship over Compromise.

Torbjörn Gyllebring 6 months later:

• • I’m with Brandon that Craftmanship over Crap is the correct one, the reasoning is here

Matt Hinze 6 months later:

• • Craftsmen produce rare, special, crafted code. Engineers produce predictable, interchangeable, reliable parts. Would you rather have 10 craftsmen on your team or 10 engineers? Yeah, sure, it’s more fun to “craft” code, but it’s certainly more profitable to engineer it.

wholesale prom dresses 6 months later:

• • The invitation stated the goal of creating a manifesto describing what all the various lightweight methods had in common. I sent the email that evening.

Thesis 8 months later:

• • The process, they told us, was that we should write a rough draft, then a second draft, then N subsequent drafts until we had our final version.

Essay Writing 8 months later:

• • Usually the Q-word is used in more restricted meanings, which takes away from its value.

essay 9 months later:

• • Well, you’re never going to need to know what 6×7 is in real life, but if you can take down Ultimate Lord Sir Barglebroth, you’ll be a hero.

Cheap Bats 10 months later:

• • With the world getting faster an faster and assmbly lines replacing skills the idea of craftsmanship has really fallen by the way side. There is little emphasis on quality or what quality actually means. Goos to read that crasftsmanship is not “pase”

Cheap Bowling Balls 10 months later:

• • I think that there is a lot of pressure of software development teams to simply produce. And they are not given appropriate direction or time to produce quality. On the other hand many software developers neither know how to communicate with those they are making the software for nor do they know how to communicate what is actually possible.

Diego Santos Leão 10 months later:

• • The Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/) says:

  • “Not only working software, but also well-crafted software”

  • So I guess what you’re saying has already been said better: “Craftsmanship over working software”, but I really believe that you should maintain the “crap” and get rid of the “we value more”, like this:

  • “Craftsmanship instead of Crap” :)

Sean Kennedy 10 months later:

• • sign me up for “Craftsmanship over Engineering”

  • I dropped out of a university Software Engineering degree because what they were teaching simply defied common sense. Fortunately my school had a good CS program that restored my happiness.

  • I’ve heard recently about how the industry has been obsessed for decades with achieving a “repeatable process” ... “engineering”, but what is really needed, and what we get with Agile is “repeatable results” ... “craftsmanship”.

  • also, if we’ve got “Craftsmanship over Engineering” we’ll get to ruffle more than a few feathers! :-)

  • And of course, it isn’t that there is no good from engineering, there are many important lessons from that discipline, but on there own they don’t give us enough, and if not tempered by something else they result in monstrosities.

Wedding Guru about 1 year later:

• • A quality product is one that pleases customers and users, while a quality program is one that merely implements functionality.

MartinP about 1 year later:

• • Myself and a colleague have had a lot of trouble trying to persuade our employers that the Agile programming approach is viable. The directors of the company are fairly old-school and come from large companies where lots of documentation is demanded. Your addition of ‘Craftsmanship over Execution’ I think sums up the potential benefit and perhaps one of the possible downfalls of the Agile Manifesto; coders using the methodology need to feel empowered and motivated enough to take care over the software they develop