Software Craftsmanship 306
| Software Craftsmanship: The New Imperative | |
| author | Pete McBreen |
| pages | 192 |
| publisher | Addison-Wesley |
| rating | 2/10 |
| reviewer | Justus Pendleton |
| ISBN | 0201733862 |
| summary | A good start with a terrible finish that answers few of the questions it raises. |
The back of the book claims that it will present an alternative method of software development, "a craft model that focuses on the people involved in commercial software development." McBreen offers his "software craftsmanship" model up as an alternative to the mainstream "software engineering" model that dominates much of the literature. It is a position that I am personally sympathetic too, so you'd think I'd be favorably disposed toward the book. Instead I found myself angry at the author for his strawman arguments, illogical conclusions, unfounded assertions, and irrelevant asides.
The book starts off well enough. McBreen points out that, historically, software engineering literature and theory have been dominated by huge projects from the military and government and small, complex, esoteric projects from academia. Neither of those extremes reflect the reality of developing applications for most developers today. McBreen offers up a method of working patterned on craftsmen of old, with a basic breakdown of master craftsman, journeyman, and apprentice.
All of this sounds well and good, but how about some details for what this means in practice?
First we have to wade through some arguments against licensing the profession. (Although craftsmen of old did that all the time, maybe he doesn't want us to extend the metaphor too far.) And then we have to read about how to be a good user. (The back of the book says it is written for programmers, so why do I need a section titled "Stop Choosing Developers Based on the Lowest Bidder"?)
As you're reading chapters like "Becoming a Software Craftsman", "Learning from Software Engineering", and "Design for Testing and Maintenance" you slowly begin to notice that none of this has anything to do with software engineering per se. After all, what is software engineering? McBreen gives a definition on page 7 taken from the IEEE:
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
He promptly forgets about this definition in his zeal to set up strawmen for his software craftsmanship model to knock over. "The software engineering view states that COBOL is a dead language with no future." "Unlike software engineering, software craftsmanship takes a long-term view of things." "A key difference between software craftsmanship and software engineering is the emphasis that craftsmanship puts on learning and coaching." "Software engineering, therefore, has to deal with the problem of developing software where incremental development and evolutionary delivery are not feasible strategies." He suggests that journeymen review the work of apprentices and that master craftsmen then review the reviewed work: "Although the software engineering paradigm might consider this type of secondary review to be a waste of time, it is an essential part of practicing any craft." "You cannot do software engineering on a low budget...software engineering projects take a lot of time...software engineering denigrates anecdotal evidence."
Where does he get this stuff from? Did I read that right, he thinks formal software engineering would complain about too many code reviews? I must have missed that issue of IEEE Software.
He seems to think software craftsmanship is somehow vastly different from this thing he keeps calling "software engineering" but anyone even vaguely familiar with software engineering literature will have a hard time spotting any actual differences. On page 113 he seems to be against "code walkthroughs" although I fail to see how they are any different from "A master craftsman...[inspects] everything that the journeymen and apprentices create." On page 124 he rails against software engineering's use of "best practices." He doesn't seem to understand that "best practices" are nothing more than anecdotal evidence and an attempt to gather and disseminate information of "master craftsmen."
This symptom is worst in the concluding section, "What to do on Monday", which is intended to be a set of things you can do to end your slavish attachment to software engineering and start out on the path of software craftsmanship. What revolutionary things does he advocate that software engineering must clearly be diametrically opposed to? He suggests we carefully evaluate the portfolio of interview candidates; pay talented staff extremely well, perhaps even more than managers; we should design for testing and maintenance; pay more attention to usability over glitter on user interfaces; create a learning environment to encourage perpetual learning.
What does any of that have to do with software engineering vis a vis software craftsmanship? Is there some reason I can't pay my developers extremely well and still have a systematic, disciplined process?
McBreen's entire premise is flawed because he doesn't seem to understand what software engineering is. His argument seems to be with a specific process, not with software engineering itself. He offers some useful advice but none of it is earthshaking and none of it is really an alternative to "software engineering." Indeed, none of what he talks about is especially new, either. It is basically the same "surgical team" model that Fred Brooks described decades ago, something he alludes to but never outright acknowledges and explores.
McBreen makes a lot of smaller missteps along the way that damage his credibility but they are really too many to enumerate. At the end of the book, you not only don't have any clear idea of what makes software craftsmanship different from a well-run software engineering shop, you also have no clear idea why you spent $29.99 on a 180 page book softcover book.
Interested readers can purchase Software Craftsmanship from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
who did it? (Score:4, Funny)
When you got up close, however, you noticed the paint was peeling, the widow sashes were rotted away, doors couldn't open or close because they didn't hang true, and at some point someone had cheaply redone the kitchen in a style that was very much not Victorian
Bejaysus! did Microsoft build your house?
Re:who did it? (Score:5, Funny)
I'd think he would've said something about the toll booth in the driveway...
Re:who did it? (Score:4, Funny)
I'll call programming a 'craft' (Score:2, Interesting)
Don't like the term "Craft" (Score:2, Insightful)
Re:Don't like the term "Craft" (Score:2)
But at the end of the day, you get paid for code that works, not code that's artsy.
Moderator on crack, again (Score:2)
What he says (Score:5, Insightful)
This is also why stuff like Extreme Programming and other strategies become popular. There are many ways to quality - all of them are task specific and slow. There is no magic pill.
Re:What he says (Score:5, Insightful)
Did you ever see the Seven Samura (stay with me here) - in it, as they were recruiting warriors, one of the interviewees asked "What's in it for me?" to which the leader responded, "No glory. No pay. And three meals a day". The interviewee laughed and said he would take it.
Another Samuri joined the group only for the love of the craft.
If coding is tedious and you don't like building your application in painstakingly slow fashion, then maybe you should find a craft which better addresses your passion, or at least try and be patient with yourself as you grow. Each project, in my humble belief, should allow you to grow as a craftsmen until you reach that nebulous peak of perfection.
We're all going to die and the apps you pump out - in the grand scheme of things - will be ultimately forgotten. So don't you think it would be better to leave something beautiful behind in the world, if only to fulfill you? (and by doing so, fulfilling the people you love)
You're right that there is no magic pill because truthfully, you don't need it.
Just my thoughts. I'll step off the soap box now.
Re:What he says (Score:3, Insightful)
Another Samuri joined the group only for the love of the craft.
Too right. I'd rather hire one person who loves what they do than five monkeys who regard it as "just a job".
Re:What he says (Score:2, Insightful)
You might write bullet-proof code, but if you finish after the product ship date announced by Marketing, you will be out of a job.
The same goes for work-for-hire. If you come in with an proposal for 6 months, and quite a few other people come in with proposals for 2-3 months, do you really think that they are going to pick you because y
Re:What he says (Score:3, Insightful)
If you want your walls painted, do you hire the guy who costs $500 and takes two days, or the guy who costs $300 and takes one day.
The first guy guarantees that he will use a coat of primer, two coats of paint, and that he will fix any defects, though there probably will be very few if any.
The second guy guarantees that there w
Re:What he says (Score:2, Insightful)
There's something to be said for finding a job you like and are good at and can contribute to society through, but I don't think that jobs necessarily are how you should make your mark on the world. Perhaps, I'm old-fashioned, but I
Re:What he says (Score:5, Insightful)
IMHO, the major problem about software in the past decade has been people's association of "oh, I can compile a C file" with "I'm a software developer". To me, anyone who hasn't gone through the final 5% of a massive project, the crunch before the deadlines that usually ends up being a death march for many, has no clue as to what is *really* involved in software engineering.
Think of it this way, any family man or woman can cook a decent meal. My parents always cooked very well actually... That doesn't make them chefs.
Anyone can cut down a tree in their back yard. That doesn't make you a lumberjack. In fact, after having seen what lumberjacks do and go through, I'm just amazed at how they still do those things.
In the grand scheme of things, nothing counts. Not the bus driver, not the stock broker on wall street, not the lawyer, not even the judge who overrules a court order... and no, not the apps [we] pump out either. It doesn't change the fact that there is definitely an art and technique involved in it.
I agree with some things you say, and I really am not answering to you in particular. Yes, there is no magic pill, and yes this guy sucks for trying to reinvent the wheel, *yet again*.
Re:What he says (Score:5, Insightful)
A well engineered project won't have a deathmarch or crunch at the final 5%.
Re:What he says (Score:3, Insightful)
It is a 'well known fact' (whatever that means) that the last 10% of a project takes 90% of the effort.
We all know it's not a fact, it's just humour to a certain extent, but the point is that tying up a project and delivering something complete is something very far from someone doodling a raytracer together over the weekend.
What makes software good isn't the ability to make the core of the functionality work somewhat. It's the ability to make the whole work seemlesly. You know it just as we
Re:What he says (Score:3, Interesting)
As a programmer by day, I'd love to take my take my time and perfect my work, but we have these silly little things called budgets, deliverable dates, constan
not realistic (Score:5, Insightful)
As a hobbyist you have the opportunity to pick and choose your projects. A working programmer often has to solve business problems that aren't unique or exciting.
Re:not realistic (Score:4, Insightful)
A working programmer often has to solve business problems that aren't unique or exciting.
Quite true. However, speaking as a programmer, I have found that even in mundane tasks I get enjoyment out of perfecting my craft. I look to make my processes just a little faster or more robust, even when doing something that I have done before (if I cannot use or do not have access to a library). I also find that the creation of new libraries is frequently needed which also allows me to perfect my ability to design and develop useful libraries.
I have worked on many projects both interesting and not, but that does not mean that enjoyment cannot be found in even the mundane things. If nothing else, I find enjoyment in the ability to pump out a simple program very swiftly without errors. There is always room for improvement.
The key, of course, to any job is to learn to enjoy what you do, even when this task is difficult. About the only time I have had morale problems with work related to people I had to work with (or insane MFC libraries... but I digress). The work of developing itself remains a joy to me.
Re:What he says (Score:2, Insightful)
Why? Because I can easily test each component. If the component doesn't work, I can rip it out and plug a new one in that does.
In other words, "Keep it simple, stupid."
Ah, who am I kidding. The toughest thing in programming is simplifing the task. I
Re:What he says (Score:2)
I agree 100%! Unfortunately, it never seems to fit into the corporate business model...
Re:What he says (Score:3, Interesting)
Yeah, and this is the guy who ends up dead... :-(
Re:What he says (Score:5, Insightful)
Coders almost ALWAYS take the quickest way (on commercial projects) Why ? Because coders are evaluated on the basis of what they get done, and how quickly. Bug counts are hardly ever relevant; in a world where delivery schedules are the ALL IMPORTANT factor, a craftsman is a LIABILITY. Assuming he doesn't get fired for not meeting the same schedule as guys who throw something together as quickly as possible and then forget about it, His wonderfully crafted, nearly bug-free, easy to use application will fail miserably, because a dozen or so crappy applications beat him to market. Face it folks, the software buying world rewards those who
1. Are first to market
2. Control the market.
Craft helps neither first, or control. Hence, the people who fund software development DON'T CARE about it.
On the other hand, Open Source and Free Software do not have this kind of profit-maximizing strategy, hence these observations do not apply.
-- Rich
Re:What he says (Score:3, Interesting)
A friend of mine is definately the tortoise, slow as it goes, programmer type. Some of the younger hackers mock him. But if you look at the total output he comes out on
Re:What he says (Score:5, Informative)
The other guy was the typical old New England carpenter. Rarely spoke, and then in as few words as possible. He moved painfully slowly, almost like he was drugged. It seemed like he never did *anything*. If you walked in on him unexpected 19 times out of 20 you'd find him chewing on a pencil and staring out in to space.
He also cost twice as much as the other guy, so we were paying twice as much an hour to "get less work out of him."
Well, come the end of a project guess who turned out the most "product" for the least money?
Yep, the old slow guy. Think twice cut once works.
What's more, the stuff "Old guy" did is still standing strong 35 years later, and still drawing comment about the beautiful craftsmanship in our house.
Mr. "Works a lot"'s stuff has all had to be torn out and redone, in more modern, and thus more expensive, dollars.
I used to be head mechanic in the largest bicycle shop in New York State's Captial district. The boss would look at new bikes I put together and whistle, declaring, "I should charge every customer $10 for your assembly jobs."
Then he'd go out and hire some hack (literally, a cab driver) to throw bikes together for $5 each. Then he'd sell the bike, and with an impatient customer waiting ask me to "prep it."
Any bike I built didn't need "preping." If I put it on the floor it was ready for Lance Armstrong to get on and ride out the door.
These cabbie built bikes I had to take apart and reassemble, a job that took three times longer than had I been assembling them out of the box, while a customer stood tapping his toes. And the boss had to pay my high hourly to do this.
At one point I went to him and said, "Look, how about letting me assemble all of the bikes and you charge ten bucks *less* for them. You'll save money."
He never did get it.
I don't work there anymore.
For the most part, and I realize there are exceptions, being a craftsman means being selfemployed.
It's a rare boss who really pays you for the value you bring to the company. What they really want is people who make "the fur fly," even if all that does is make a bloody mess.
KFG
Re:What he says (Score:3, Interesting)
So, the software buying market also often rewards those who work the hardest and make the best games. Usually. There have been a lot of good gam
Re:What he says (Score:2, Funny)
Re:What he says (Score:3, Insightful)
Neverwinter Nights, I felt, was actually pretty good. It's a big effin' engine. It just won an award at GDC for excellence in programming. A group of our PEERS decided that the job that we did was quite good, and I agree. As for these 'significant crash problems' I don't know what you're talking about. I played BGII all the way through 5 or 6 times, and don't remember having an exceptional number of crashes. I don't really remember it crashing at all, actually.
Unreal 2 is a fine
Huh? (Score:5, Funny)
Don't read slashdot much, eh?
Read Pragmatic Programmer (Score:5, Informative)
While I liked it, and found it a nice framework in which to hang many thoughts on, I would recommend 'the Pragmatic Programmer' by Andy Hunt and Dave Thomas over this book. McBreen actually quotes that book so often in this one that I often wondered, "so, what was the point of this book then?"
Re:Read Pragmatic Programmer (Score:3, Informative)
That book is currently out of print, but the author has a website with the contents of the upcoming second edition.
http://www.stevemcconnell.com/gr2.htm
Re:Read Pragmatic Programmer (Score:5, Funny)
Such a multi-talented man Dave was. I still prefer Wendy's over any other fast-food restaurant. So the 'Pragmatic Programmer' has an extra-spicy approach to coding?
*ducks*
Re:Read Pragmatic Programmer (Score:2)
Re:Read Pragmatic Programmer (Score:2)
Well then (Score:2, Interesting)
Re:Well then (Score:2)
Hammer != Compiler (Score:3, Interesting)
It would be pretty hard to repair the shoddy 'windows' on our 'house' if they are all licensed by Microsoft.
-S
Meta-Programming books suck (Score:5, Informative)
Re:Meta-Programming books suck (Score:2)
Methodology books aren't completely useless, provided you avoid slavish adherence to any one approach. The best approaches to software development have to take into account not only the actual task at hand, but also indirect (often economic in the case of commercial development) factors: expected life cycle, cost targets, hard release dates,
Re:Meta-Programming books suck (Score:2, Insightful)
Re:Meta-Programming books suck (Score:3, Informative)
Even though it is written by an ex-MS programmer and from MS Press it is a very good book. Maguire worked for them before they tried to take over the world. His "Debugging the Development Process" is a bit more preachy and less useful (but still a good read).
Re:Meta-Programming books suck (Score:4, Interesting)
Re:Meta-Programming books suck (Score:2)
Patterns are always used when just about anyone writes code, unless the writer is doing something completely novel. The movement behind the whole pattern thing is simply to publish these, so we don't have to constantly re-invent the wheel. As such, patterns aren't something that's simply "interesting to think about".
Framing user requirements is another animal altogether and has nothing to do with design patterns at all, except to the extent that the patterns c
Re:Meta-Programming books suck (Score:5, Insightful)
Design Patterns suck (Score:4, Interesting)
According to Peter Norvig [norvig.com] and Greg Sullivan [mit.edu], most of the patterns in the Gang of Four book are there to show users of common OO languages the canonical ways of getting around design flaws in those languages.
Norvig says 16 of 24 patterns either vanish completely or are significantly easier to implement in a dynamic OO language like CLOS or Dylan; Sullivan implements a tiny OO language in Scheme and uses it to implement all 24 patterns, with similar results.
Go read the papers before modding me down, huh?
Re: Singletons suck (Score:2)
I use it as an example frequently, because it is the most simple pattern and the one everyone seems to understand the best.
Personally, my favorites are the visitor and interpreter patterns.
Re: Singletons suck (Score:2)
I agree, everyone's been ripping off "Boyz n the Hood" for years.
From recent experience (Score:5, Insightful)
I don't consider myself a "professional" Perl programmer, though I've had several years experience, but even I can see when a large system is made up of a lot of little shyte.
Another thing one might notice in particular, is on group-programmer projects. The interface coding might be very nice, and then when one goes the the back-end modules that query mySQL DB's, etc... it's obvious that it was a different and less experienced programmer.
When I start seeing things like:
$stuff[1], $stuff[2]
$blah
etc
it scares me. If code isn't going to be commented, at the very least the variables can be intuitively named so as to make sense, and using arrays of hard-to-determine crap for no reason is just bad (at the least, use named hashes, or just normal vars).
Re:From recent experience (Score:2)
The conclusion that I have come to accept as the truth, or a close enough approximation, is that pointy-haired, computer illiterate bosses want a product. If a developer goes in and shows the boss or manager a really nice piece of MySQL connection code, the boss' eyes are going to glaze over and a girly tantrum is likely to emerge.
Re:From recent experience (Score:5, Funny)
Version 2.0 will replace all of your comments with your phone number and an increased salary demand.
Re:From recent experience (Score:5, Funny)
10) Åccented Letters: Use accented characters on variable names. E.g.
typedef struct { int i; } ínt;
where the second ínt's í is actually i-acute. With only a simple text editor, it's nearly impossible to distinguish the slant of the accent mark.
and:
15) Names From Other Languages: Use foreign language dictionaries as a source for variable names. For example, use the German punkt for point. Maintenance coders, without your firm grasp of German, will enjoy the multicultural experience of deciphering the meaning.
Yeah! Hear hear! (Score:2)
actually, there is a perfectly valid reason to use arrays: Bounded latency, specifically for real-time code. Give me and array; the size of its elements and its size, and given how paging is on the target platform I can give you a Big O of how long it will take to iterate through. thrashing (excessive paging) suxxors.
I realize that had only tangential relation to your comment about arrays of hard-to-determine crap, but this is slashdot.
Re:From recent experience (Score:2)
If code is going to be commented, you are fired. Solves that whole issue. What's so difficult about that?
Must be a freshman... (Score:4, Funny)
Re:Must be a freshman... (Score:3, Funny)
Another article by McBreen (Score:5, Interesting)
Also, it may be hard to believe but having worked with Pete on the project that was "Crashed and burned" I can testify to the fact that the article is in fact non-fiction.
Re:Another article by McBreen (Score:2)
Use EJBs
Seriously, I have heard of 4 or 5 major failures and no major successes with these things. Entity Beans are about *the* most complicated and complex way of doing O/R mapping, there's very little you can do with Session Beans that can't be done with static functions (stateless) or regular objects (stateful), and the best practices with business delegates and facades gives you like 5 or 6 l
Re:Another article by McBreen (Score:5, Interesting)
Of course, we couldn't eliminate EJBs entirely, because our customers really wanted it to run with the Weblogic 6 licenses they had bought (woe befalls he who tries to explain that if you are going to use EJBs, you might as well use JBoss since it's a ton faster and generally more reliable than Weblogic, and pretty well supported through their online forum). But then again the customers wanted to know they could call Weblogic with a problem - of course, Weblogic would never really be able to help them anyway (I know, I've tried their "support").
Yup, basically I would never use EJBs in pretty much any project I can think of again, since they just don't solve enough problems to be worth the pain and hassle. What they DO provide, and the reason people use them, is an application "blueprint" for teams without a decent architect to solve their structural problems. It's just possibly the worst such model imaginable, and it's truly sad that this model has caught on. If you want a framework for a truly distributed, reliable, scalable framework, Jini and, say, JavaSpaces provided MUCH more interesting options, but had no corporate acceptance. If you had REAL problems that require a distributed framework, this was the way to go, since EJBs have absolutely no awareness of the location remoteness features they provide built in (resulting in a potential mess of RMI shit in all but very, very simple systems). Which, in short, is why everyone ends up scrapping entity beans.
Ugh. Thanks for reminding me why the enterprise software business sucks so much.
Software Engineering is different in Purpose (Score:5, Interesting)
Software Engineering: make the development of software a controllable business process.
Software Craftsmanship: make the best software.
The basic notion of software engineering is to create a *process* which is so perfect that no personal weaknesses in your programmers can hurt the company. A subtle side effect of this is that it also tends to prevent any extremely great individual contribution from having a large impact. That is, the goal is to make all of your coders cogs in a machine. The business owners and managers would much rather have this setup because it makes it easier for them to sleep at night.
Re:Software Engineering is different in Purpose (Score:3, Insightful)
This is a very dangerous notion, and I disagree with it.
Engineering is about creating technology. It's unfortunate that most "Software Engineers" are clueless doe-eyed grads or uneducated bureaucrats, but that is a symptom of the overall immaturity of the industry. It's unfortunate that the overall credibility and quality in the software industry is
Re:Software Engineering is different in Purpose (Score:2)
You see business people (classicaly) thought of their engineers as the people designing the product and their manu
Re:Software Engineering is different in Purpose (Score:4, Interesting)
Whereas engineering is about reproducable, and measurable processes that can be constrained within certain bounds, craftmanship is about being able to build things that serve a purpose.
To some degree a craftsman will delve into a standard repetoire of tricks and techniques to get a job done, reflecting the "engineering" aspect of the job. However, what makes a craft interesting is that no two assignments are alike, and the job-specific problems, and how they are solved separate the master from the novice, not mere knowledge of a larger repetoire of canned solutions to known problems.
Because programming is such a young discipline (as opposed, say, to building buildings, bridges, or even airplanes), there is a log of original craftmanship involved in most projects. When a design pattern is found to be useful, it is catalogued, communicated, and often finds generic implementation in some piece of code, or higher-level programming language -- application-specific languages, or languages "tuned" to be particularly useful for certain applications reflect "software engineering": we've solved this problem, this is the general approach, and here are the parameters within which this solution works. A design pattern, implemented, becomes a "rough in" of a piece of code.
What this means, of course, is that the repeatable stuff becomes engineered, leaving only the "finish work" to be crafted. Leading edge programmers pushing the envelope of what the "finish work" is are thus craftspersons, and commensurate with the original work they do, notoriously unable to provide time, complexity, and labour estimates: when the job is done, they will know how long it will take.
This, of course is frustrating to traditional management teams. For software is not like a house. The interesting stuff, and the stuff that sells as the next "killer app" is precisely the stuff that no one has yet produced, reducing it to a low-margin commodity, instead of the "hot" program it is. And this stuff is not engineered -- it is crafted.
Software patents and copyrights ensure artificially high value for what would otherwise be commodity software, restricting its proliferation until it is ubiquitous, and commensurately high salaries for "assembly-line software engineers". Without them, the high-margin areas would be those of the leading edge, crafted code -- protected by copyright and patent for a short duration, perhaps, to encourage progression of the art, and recoupment of development efforts.
Interestingly, some 95% of all code is not engineereed according to a simple blueprint, but custom-crafted, Microsoft Office sales duely noted. Even if you can buy all the pipe and fittings you need, a plumber to cut things to proper lengths is handy. If all commodity software were free, there would be plenty of employment for software craftspersons (on this, I agree with RMS). Software engineers, in the guise of assembly-line coders, would be relegated to the ranks to apprentice, or "do it yourselfer". Perhaps when this happens, true software engineering, that is the polishing of a custom crafted design into a generic cookie-cutter component, understandable and consumable by the apprentice, will properly refer to the master software craftsperson.
Interesting Software Engineering publication (Score:4, Informative)
Comparing programming to "real world" endeavours (Score:5, Interesting)
If one MUST use some real world analogy, then imagine wanting to build a dresser. You come up with the requirements, must have four drawers, have certain dimensions, be made with a certain type of wood and be stained to look a particular way. So you start buying lumber. But wait, no one carries just the right type of lumber you want, so you run out and cut your own tree down and make the lumber yourself. You decide to dove tail the drawers, but the dove tail rig you have doesn't quite fit, so you kinda work around it and get "good enough" dove tails. Uh oh, you never checked with your wife on those dimensions, she wants something 6 inches wider, gotta take those drawers apart and make wider ones, do you cut more trees down, or do you patch an add on to the existing pieces? That last one put you behind schedule, so now you don't have time to actually check your work completely as you go and your carpenter friend Bob has a baseball game to go to, so he can't help with that tricky scroll work you need to do, guess you'll just go online and just copy what someone else has done. etc, etc.
Not to mention that few software projects have such simple requirements. This dresser has to actuall fold the clothes for you, let you know how many socks are present, pick your wardrobe for the day AND it has to look pretty, interface nicely (dooh, made those knobs too small to grab), etc, etc.
And lets not forget one of the biggest project killers, you decide to build this dresser with four of your friends, each doing a different part. And dang it if those drawer openings are too small. And the trim around the edges are 1/4" smaller than the trim used for the mirror, and those pilot holes are 3/8" but your using 5/16" screws.
You get the picture. Nothing like this happens in the real world, software is a completely different beast and to contrain it by using realworld analogies might push a few books, but it's not making software engineering or the software being produced any better.
Re:Comparing programming to "real world" endeavour (Score:2)
This is still my main gripe against acedemics in computer science fields. They think they need vastly new methods of teaching for these "new fields." While some adjustments are indeed necessary, please don't just try to reinvent everything. You can still use existing methodologies and such, but you have to understand them yourself.
For instance, the dresser may be a bad example. But only b
Re:Comparing programming to "real world" endeavour (Score:2)
The dresser is part of a whole. Specifically, it is part of a place of residence.
The trick is finding the ones that do work, and taking advantage of them.
But that's the problem. It's NOT like building a house, only in the crudest sense. Currently we're still banging nails out of scrap metal. We're still lashing hammers out of sticks and rocks. There are lots of screwdrivers out th
Re:Comparing programming to "real world" endeavour (Score:2)
My argument is that that is counterproductive. The point is not to come up with one golden example that describes all we need. Instead, the trick is to understand what parts of other trades we do need to learn from. This includes house building, bridge building, book publishing, etc. If you can't find som
Nope, never happens in the real world (Score:2)
Re:Nope, never happens in the real world (Score:2)
No, not that the errors don't occur, the nature of what is trying to be achieved doesn't happen in most other things that are done (i.e. the fluid nature of the infrastructure we design on). Engineering f* ups will ALWAYS occur, no matter how big or small, I don't see how I was saying that this wasen't the case. Of course any "real world" projects that depend on software also suffer similar issues.
Re:Comparing programming to "real world" endeavour (Score:5, Insightful)
This type of thing happens in the real world ALL THE TIME. Talk to anyone who has had a home built for them. Critical people or equipment doesn't show up on time, structure is far more fluid than people ever suspect, and what was presented to the customer via blueprints and models still may not be what they were expecting.
Engineering is knowing when to say good enough. A component performs as specified in the requirements. That is, if they say they need a hinge that will hold an aluminum door they don't build it out of titanium. For cranking out code, this is really an art. XP touches on this (and goes to far IMHO) about focusing on the task at hand rather than building large frameworks, object models, etc. There is a balance there, but for most construction these days the spec is 'good enough'.
Craftsmanship is taking the time to make sure every stud in the house is square. This is not an engineering requirement - the requirement is to support the wall. This is about polish and taking extra time to 'do things correctly'. It takes time, usually is not budgeted, and is a godsend to the folks having to maintain it down the road. These things also tend to live far beyond everyone's expectations. Think of some of the deep space probes landing on asteroids - craftsmanship. The mars lander comes to mind when you mentioned bolts.
Craftsmanship is also about using the right tool for the job. As I learned some basic carpentry skills, my grandfather would comment 'Any power tool used improperly can be a sander'. This applies to the real world as well as software. Let him that has not done an ugly hack throw the first stone - but duct tape and bailing wire are staples of engineering jokes because they are about getting the job done, but not in an elegant manner.
When I build stuff for others, solid engineering is enough. For my personal projects, I expect craftsmanship.
Course, I have not seen the book, so I may be way off track here...
Re:Comparing programming to "real world" endeavour (Score:2)
I was not saying that every house built is perfect. Obviously there are always logistical issues and problems that always occur. The point I was trying to make (and apparently unsuccessfully) was that the basic foundations of software engineering are quite different than those in the real world. We don't have building codes and a fundatmental understanding that a roof of a certain weight and composition has to be built using certain materials in
Re:Comparing programming to "real world" endeavour (Score:3, Insightful)
I know... I'm just going through the process right now and the real world seems as horked up as some of the ugly software projects I've worked on. Call me cynical, but I've got friends in differing areas of engineering - aerospace, mechanical, electrical, genetic - and all of them have nightmare stories of projects that were loosely defined
What I tell my group (Score:5, Insightful)
- code reviews on every check-in
- lots of refactoring
- incremental releases
- constant testing
- individual 'craftsmanship'
So what do I tell my group? I tell them "any piece of code you write you should be proud to show at a job interview."
And I lead by example.
No big surprise here (Score:5, Interesting)
2. That the /. review(sic) is incomplete, biased and (imo) less useful than the reviews on Amazon/BN.
His credentials seem ok, the excerpts looked interesting and relevant and I think his approach is a viable one (which is not to say it's the only or best one for any given circumstance).
Modern software engineering(sic) doesn't seem equal to the challenge that many (cough-MS) organizations developing software emphasize absolutely as many features as can be crammed into the deployment space, with reliability criteria seemingly like "if it's not so unstable that the customer will ask for his money back, we ship it".
Ok that's the current market and goodness knows people keep buying and writing bloated, buggy software is by no means limited to commercial/priprietary, it's become all too common in free/oss projects also. (See my related views [slashdot.org] about that).
The mantra that seems to drive the market is "More features". Personally I beleive the best programs result from the alternate view: "The best program is the smallest program that fits the need".
So wherever the statement "If buildings were constructed the way software is constructed, the first ant to come along would destroy civilization overnight" remains true, I think the applicability of "software engineering" is (nil).
Re:No big surprise here (Score:2)
If fact, it sounded like the reviewer really wanted to find something new, maybe even a little "holistic", and didn't find it in this particular book.
I think, rather, that the reviewer is commenting on his opinion that the book sucks rocks and doesn't do a thing to advance the author's arguments, nor does it suffici
Look. (Score:5, Interesting)
Software Engineering has a substantial creative component to it that is far more akin to music or art than to other forms of engineering.
And just like music or art;
* a few of us are REALLY GOOD
* some of can perform the programming equivalent of playing "Three Blind Mice" on the piano
* and some of us SUCK.
Trouble is, in the IT industry, as opposed to other creative industries, there is little salary difference between the three.
Why no salary difference -- Re:Look. (Score:3, Interesting)
One reason is because the people making the money descisions are under the illusion that software is not a create industry. They think it is 'Engineering' in the sense that anyone who can add the numbers can do it. But if that was true than we would
Re:Why no salary difference -- Re:Look. (Score:2)
I think the "Performance Review", or "Appriasal" (call it what you will) effectively breaks down when the person being reviewed has significantly higher career aspirations than the reviewer.
Reviewer: "Where do you see yourself in 5 years time?"
Reviewee: "Your boss."
Reviewer: "Right, ok that will be all."
Career aspirations (Score:2)
So my career aspiration is do more of what I do now, but to have a little more control on the technical issues in those cases where I really am the most qualified to make the descision. I have no problem deferring to someone else when they really are better or more informed mind you. But s
Re:Why no salary difference -- Re:Look. (Score:3, Funny)
Reviewee: "Your boss."
Reviewer: "Right, ok that will be all."
If you're smart, you'd say "still reporting directly to you...but you're the president of the company". That way, you shouw you're politically smart and not just ambitious.
Re:Why no salary difference -- Re:Look. (Score:2)
How to tell a star performer (Score:2)
Reading
Re:Why no salary difference -- Re:Look. (Score:2)
Not only does managment think programmers are all equal but rather they a.) waste money b.)Are just commidities c.)Worth as much as the highschool dropout at McDonalds and should be compensated as such since they do not bring in money anyway.
They count the beans and say how much money does Bob
Save your money... (Score:3, Funny)
The house that love built (Score:4, Insightful)
I sometimes wish we were working on an old house, as our house was flying down the street at the speed limit, and no one was willing to stop to make the required repairs.
How much can craftsman programmers learn when their walkthroughs are confined to the sample home (development environment)? They rarely go near a lived-in home (production environment) and may have never talked to an actual homeowner (customer) in their entire career.
Widow sashes? (Score:2, Funny)
If my house were full of bereaved women wearing decomposing ribbons, I wouldn't be worrying about the peeling paint...
Best Practices (Score:2)
Craftsman/Journeyman/Apprentice not always great (Score:3, Insightful)
My family owns a home-improvement business (I don't work there now, but did summers during college) and often deal with builders who work on the principle described by the author.
On more than a few occasions when I worked there, I would go to hang rain gutters (on new homes) and find all sorts of messes: Corners not square, roofing materials cut way too short or way too long, roof vent holes that have had shingles nailed over them, and even more idiotic and egregious mistakes than this--All of them perpetrated by either apprentices under supervision, journeymen or mastercrafstmen. Usually, it was the result of a project that was behind schedule and needing to cut corners to catch up.
My point? It doesn't matter what "Quality Assurance" system you have in place if you set unrealistic goals and/or hire the cheapest labor you can get your hands on.
forget the review (Score:3, Interesting)
Since the code can't be seen, then it can't be engineered. I suspect that software will remain a craft until code visualization tools progress to the point where I can look at a visualization of someone else's code and understand it in a general sense almost immediately.
simon
My notes of Software Craftsmanship (Score:5, Interesting)
Notes of interest:
- JWR
New programming paradigms... (Score:5, Insightful)
I'd like to add my two cents, so here it is:
Every year or so, some wingnut comes out with a "brand new paradigm" of software development, which is supposed to totally shake up all established practices and change the world overnight. And, it's all hogwash, but inexperienced programmers and the wannabes who take the six-month-special course in a back alley in NYC hoping to make it big in "Computers" all jump on the bandwagon and make life miserable for the rest of us. I've been programming in one language or another since 1991 (although I've been using computers since 1983 or 4); I started studying it formally in 1995, and I've been working full time as a programmer since 1998. And, in all that time I have never seen anything come out that does a better job than plain, old software engineering.
You know what I think?
I think that in this age of "bigger, better, faster, more" people who can't make a name for themselves by building/doing something USEFUL try instead to become "visionaries". So they pull some weird new way of programming out of their asses, serve it up to us like it's filet mignon, and sell books about how to change everything you're doing yet again. This constant change prevents companies from building stable software. How can you work all the bugs out of anything, when every five minutes you're changing all your processes? As if the huge amount of turnover, outsourcing, and downsizing doesn't make long-term software development hard enough.
The worst thing is, managers assigned to IT teams frequently don't know enough about software engineering to understand the difference between one paradigm and the next. So they end up running willy-nilly from one to another, changing boats midstream in a doomed, Frogger-like attempt to not get sunk in the next layoff. Any new book that catches the manager's eye mesmerizes him.
Heaven help the gullible manager who ends up with an aggressive little ivy-league grad that wants to make a name for himself. Then the manager's gonna be led by the nose. After all, what does a manager respect more than pedigree? It doesn't matter that the kid's balls haven't even dropped yet, that he has no experience on any real project, that the closest he's come to load balancing is two PCs in his dorm room, serving static web pages to one user who keeps hitting "refresh"...
GOD.
When, oh when, will people learn?
We've already figured out how to manage software projects. We've understood what works and what doesn't for at least a couple of decades. The field is fairly well researched, so there is plenty of material available about software engineering, and all you have to do is go look it up. There's NO NEED to keep trying to change the process.
Feh. Snort.
Re:New programming paradigms... (Score:3, Interesting)
Yes, I am a curmudgeon. And, I am very jaded, from working with some of the very ding-bats I complained about. But, you're off the mark on some of your points, and I'd like to mention why I think this is true.
First of all, TRUE software engineering works just fine. That is, if you have a team which is committed to the basic principles involved, i.e. design your solution first, unit test everything, use a
Re:New programming paradigms... (Score:3, Interesting)
You're probably right. I found that on a web site, but now I'm not so sure if it meant the kernel or an entire distro.
You're stuck on the idea that one person can only understand 1,000 lines of code. Where the heck did you get that figure?
The mental picture I'd like to convey is the author emerging from the project, completely convinced that there are zero bugs. Any other expert who has not seen the code can read it (taking weeks or months a
Personal Responsibility (Score:3, Interesting)
I have read Software Craftsmanship. I have also read extensively in the general field of software development methodologies, software engineering, and project management. On thing that this book does, that is very rarely dealt with is the personal responsibility that one has as a software developer. Most methodologies are designed, in essense, around the idea of minimizing the human impact on the bottom line. Software Craftsmanship deals with this question to a superlative degree.
One thing that I found lacking is the issue of why exactly craftsmanship is a better model than software engineering. There is some discussion of this, and although I agree with the conclusion, it was not very well supported. My feeling is that engineering works for physical structures where humans intuitively understand the rules and the use of the structure follows the same rules as the creation of the structure, but in software, you make up the rules themselves and the rules are different for the process of creation and the actual use of the software!
Another two books which deal with the question of personal responsibility are Extreme Programming Explained by Kent Beck and Agile Software Development by Alistair Cockburn. If you are interested, I have compiled a list of resources for people interested in creating software [berteig.org].
Re:personal attacks (Score:4, Insightful)
Re:personal attacks (Score:2)
Re:personal attacks (Score:3, Insightful)
Re:lameness detected (Score:2, Insightful)
That's why they call it "Review" (Score:3, Insightful)
Re:lameness detected (Score:2, Funny)
Robert