Slashdot Mirror
Software Craftsmanship
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.
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?
this sig steers like a cow. and i can prove it
when programmers unionize.
Cretin - a powerful and flexible CD reencoder
Is Orson Scott Card behind this somehow?
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.
Don't read slashdot much, eh?
sulli
RTFJ.
Problem is, these days, most of the code would be written by journeymen, even the king's most mission-critial software (i.e. Windows, upon which the modern world is based).
I have read this book.
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?"
What books WOULD you recommend, if this one sucks rocks?
Great work with the cheap paneling covering all the holes in the plaster too.
Bastard.
for a book review that seemed to have alot of personal attacks against the auther... but overall I found it to be interesting and well written
Selling software wont make you money, selling a service will.
We can buy trashed houses and fix them up to our hearts content... will these new Software Craftsmen also be open source advocates?
It would be pretty hard to repair the shoddy 'windows' on our 'house' if they are all licensed by Microsoft.
-S
We Apprentice Developers and Designers
Robert
There is only one book that preaches a methodology that I have found useful (and I have read several), and it is more of a programmers cookbook than a strict methodology. Design Patterns from Gamma, Helm, Johnson and Vlissides. It gives you exactly what you need as a programmer: the ability to communicate volumes of information about your system to me with a few key words. For example, if you tell me that your logging system is a Singleton object, I immediately understand its' place in your system and how to use it.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
I've seen a lot of apps - especially web-based ones - that look great and are coded like crap. The problem with somewhat simpler languages, especially scripting languages, is that the ease of learning the basics often leads to some very undereducated programmers.
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).
and not "Advertisment."
What were you expecting?
It sounds like whoever wrote this review just got done with Philosphy 100 at the local community college and is eager to show off his/her stunning analytical abilities by bringing up every single fallacy mentioned in the class. It probably gave him or her a sense of accomplishment or something.
I think he's trying to set himself up as the Hoffa of software development land
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.
Contrary to what the author of this review is saying, I really do think that software engineering is different from software craftsmanship. Although you can take many of the things said about software engineering and come up with an application of them similar to an application you could come up with for software craftsmanship, but in practice you wouldn't. This is because the underlying philosophies are very different, and they exist for different purposes. The philosophies/purposes break down like this:
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.
:Wq
Not an editor command: Wq
Bruce Weide of the Computer Science Department of the Ohio State University has been working for several years on a way to introduce software engineering principles to first year computer science students. It's an interesting read (albeit one that was forced on me for my classes) and is available for download here in pdf format.
I always find it amusing to read about people who try to compare programming (or software engineering, or whatever) to things such as house building, or even more general like "master craftsman", apprentice, etc. One of the biggest problems facing developers today is the overwhelming complexity of the software being created and the environments they are being created in and the pressures of getting said software done in a particular timeframe.
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.
I run a small software group writing control code for semiconductor processing equipment. I read a lot of literature and what works for my group is:
- 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.
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 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).
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Come on, it's more of an art. What's better than constructing an elegantly written piece of code. Granted, most programs are closer to a "Cathy" comic strip than a Piccasso, yet there is something so nice about the occasionally beautifally crafted script.
There is no magic bullet or even way of thinking that is overnight going to make IT projects run on time and on budget.
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.
Singleton has got to be the most over-used pattern ever. There are hardly any legitimate cases for a singleton, yet it's the first pattern anyone learns. They then go off and litter their code with the bloody things.
Yes, Singleton is overused. My example of a logging system is one of the few times I have found it to be appropriate: you need logging from everywhere and it sucks even worse to instantiate an object when you need to write to a log.
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.
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
...and buy a copy of the "Extreme Craftsmanship" book that is sure to come out next year.
I have seen negative reviews here before. A handful of 8's and even a couple of 7's.
Remember, anything under a 9 is a bad review.
...but,what does the reviewer mean when he says, "the widow sashes were rotted away" Slashdot readers need to know,bcoz we cannot tolerate 'slepping' mistakes:-)!
We took to calling our ERP software that we we're responsible for supporting and customizing "The house that love built." It had a long history of many owners and installed base in critical production environments. Despite the desire to burn it to the foundation to fix it, we were limited by time and money. We had plenty of ugly interfaces that put the toilet next to the refrigerator, load-bearing posters, and if we ran out of floorboard, we weren't above painting the dirt.
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.
Preach On! The only part missing is the fact that the wife changes her mind every other day about what she really wants...
When you got up close, however, you noticed the paint was peeling, the widow sashes were rotted away,
If my house were full of bereaved women wearing decomposing ribbons, I wouldn't be worrying about the peeling paint...
But it is attitudes like this that will cause you to repeat all of the mistakes already known by other professions.
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 because it is in a different scope. The dresser is part of a whole. Specifically, it is part of a place of residence. If you have a programmer and give him a huge unbreakable task (such as building a "project"), then don't be surprised when it doesn't turn out. Instead, realize that you should give individual programmers components of the whole program.
My point, I guess, is that you can always come up with examples that don't work. The trick is finding the ones that do work, and taking advantage of them.
It seems to me where this book really falls down is here: whereas developers will always think of software development as an art, project sponsors do not. They have no way to place value on the quality of a system, including ease of maintenance and extension. This differs from other disciplines which are considered crafts, since consumers differentiate quality there.
But it is attitudes like this that will cause you to repeat all of the mistakes already known by other professions.
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 there, but none seem to match the screws that we want, or force us into compromises that we don't think are good.
What I'm getting at is that you can't use the concept of canning jellies into making a good pot roast. Apples and oranges. What makes things like house building and car building possible is that it's foundations are stable. Engine putting power through a piece of steel through a transmission, through another piece(s) of steel to get to the wheels. You can certainly tweek parameters, but the foundations are what they are. Software has yet to get to that point, and until they do, no amount of trying to apply physical world theories are going to make any dent.
It's not like problem partitioning is anything new in software development, we've been doing that for years. The problem is that the problem grows at a rate that is faster than the solutions and those implementing those solutions. Imagine trying to be a house builder if the fundatmental nature of wood kept changing every five years. Or new materials were being adopted at that pace (first we use wood, now we use steel, now we use concrete). So I think that our problems are unique, not that existing theories can't be applied to "help", but something "different" has to happen to "fix".
I agree, everyone's been ripping off "Boyz n the Hood" for years.
This may seem slightly off-topic, but bear with me, and the relevance will become clear...
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.
Who did what now?
A few months ago, whenever Slashdot ran a book review, he'd immediately post a link to Amazon.com. Whenever he did this, he included his Amazon associates ID.
Many slashdot posters were disgusted by this parasitic behavior. Slashdot has a tough enough time generating revenue to stay afloat, and this guy was skimming the cream off of one of Slashdot's few revenue sources.
I think somebody reported Ralphie to Amazon, because another AC threatened to do that, and then RedWolves2's links disappeared.
But now he's back with a new trick. Rather than embed Amazon Associates links directly onto Slashdot, he's registered a site to do his dirty work.
In today's review, he points readers to his page, which seems to exist for no other reason than to feature books reviewed on Slashdot. Naturally, Ralphie's never forthcoming about what he's doing. Neither his Slashdot posts nor his website informs readers of his affiliate profits.
I worry that Slashdot will run out of revenue before it finds a viable business model. For all its faults, Slashdot is a valuable site. And it disgusts me to see someone like Ralph Whitbeck bleeding the site of potential revenue.
using the analogy of the victoria house as a software project. my house would have been condemned from the first day that construction was begun.
we have contruction workers, plumbers, electricians, etc who have no idea of what they are doing aside from two weeks of training and a manuals (which they refuse to read). (i must admit that i too started with a lack of knowledge, but have made an effort to increase mine by all means available.)
it is a mess.
andrew
Why did I lurk so long before registering for a Slashdot account? I could have had a Slashdot ID of less than 100000.
I haven't read the review and I'm not going to. The idea that software is a craft is right on. Managing a successful software project is much more about getting the right people on the job and trusting them to write good code, than it is about engineering practises. Software is invisible to anyone but the active coder. That's the whole point of good APIs -- they are very small, understandable interfaces to the invisible code.
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
home page
I always find it amusing to read about people who try to compare programming (or software engineering, or whatever) to things such as house building, or even more general like "master craftsman", apprentice, etc
Whenever I hear an argument like that, it usually compares software to automotive companies. I like to remind them that if they want to use that comparison, then their automotive companies must be as adaptive as software.
The functional requirements (not just styling) change every year. Your customer base expands by orders of magnitude every year, requiring more and more support. The environment that the product runs in (rails, roads, rivers... whatever) changes every two or three. The actually product changes every five years... changing from building cars to airplanes to submarines. The materials used to build the product are completely replaced every ten years. The consumable (fuel) that that product consumes changes every four or five years. And you have to do all of this in six to eight month product cycles.
You can't rely on last years model to provide a base for next year's with all of those changes.
Like when they designed the last 4 US battleships, somehow two teams got confused on turret size, I believe it was for the 5" turrets, had to do some quick re-engineering to make them fit. No, nothing like that would ever happen in real engineering, noooo, software engineering is soooo special...
Infuriate left and right
Notes of interest:
- JWR
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.
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...
+++ UGUCAUCGUAUUUCU
Your breakdown into three programmer types is nothing new. It is widely documented that out of a group of ten programmers two will be as productive as the other eight put together. So why aren't these 'star performers' treated (and paid) like the stars they are?
.'
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 already have self-programming computers. Seen one recently? When was the last time you actually used a '4GL' in a real-world scenario? Not a good example maybe; that doesn't really qualify as self-programming anyway. More like 'canned programming'.
Nonetheless, take a close look at those people who are 'really good' programmers. In my experience you will often find they are also musicians or skilled at some other creative endeavor in a much higher percentage than the average public. This tells me that one of the things it takes to be a top programmer is the same thing it takes to be a great guitar player -- innate talent. Either you have it or you don't. And if you don't have 'it' no amount of schooling will make you more than adequate.
But that leads to the second reason why you don't see the salary difference: Good programmers are often not seen as team players. They tend to be 'Prima Donnas'. They get angry when people don't listen to them as they go against the political grain in an attempt to do something the 'right' way. In other words they usually just aren't as likeable as the 'other eight'. And the fact that events usually prove the star programmer was right all along only leads to more friction.
The third reason for the salary difference is just plain silly: Performance reviews. I have yet to see a supervisor who was comfortable giving a star performer a star review; something on which a significant salary raise might be predicated. But without the good review the raise doesn't happen.
This might be because the supervisor is acting on personal feelings "She is good, but she has been difficult to work with this year." It might be because the supervisor feels uncomfortable giving extreme reviews in either direction. It might be because the supervisor fears that the star performer will be promoted away (or worse, over them) if it were clear how good they are. And I am sure a hundred other reasons as well.
I certainly know how hard it is to show up with a good attitude every day knowing that only the quality of your code is the difference between you and Joe Schmuck, who can't program his way out of a paper bag. But even more than the money I just want them to start LISTENING TO ME! I can't tell you how many times I have been hired as an expensive consultant, given them my professional opinion and then watched them do it the wrong way anyway. Over and over. Always smacking into the very same brick walls I warned them about.
So, if you are a supervisor for programmers I hope you take this rant to heart. You might also want to take my handy test: 'You might be a PHB if . .
- -
Are you an SF Fan? Are you a Tru-Fan?
Change "Master programmers (craftsmen) should be paid more than many programmers." to "Master programmers (craftsmen) should be paid more than many managers."
These are all the buzzwords of today merely putting banaids on the gushing exposed arteries of the software industry. People read these books and half implement the parts that sound good to them and completely ignore the important ones.
Today's software market will not tolerate holistic software engineering except in rare cases. In fact, most schools teach the "craft" of software engineering ass backwards. Instead of permeating the curriculum with software engineering concepts such as coding standards in CS 100 (and failing people who write out of spec, etc) to submitting models before submitting code and then grading based on accuracy to the models and on the actual quality of code. 99.999999999999% of all software classes, even the ACM's own college level programming contest, grade only on 1) does it work and 2) how fast can you get it done. They never even look at the code. People do not come out of college with the skills to engineer software and corporations are too interested in the bottom line to pay for people to learn these concepts, they want canned talent that know how to program well and that's good enough.
eXtreme Programming, software craftsmanship, etc are only buzzwords made to pray on weak minded developers that are desperate for results. If you want to save the industry, you'd know selling a book on amazon won't do it.
That is the worst part -- I am a consumate geek. This means I don't want to be anyone's boss really. I just want to do cool things with cool technology. And I would like to be paid relative the fact I am quite good at it.
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 someone who hasn't written a line of code in ten years and only knows about the project what he hears in design review meetings just doesn't qualify that way.
OTOH I am working as a consultant now, which means I most always keep the politics and the on-site developers needs in mind. And accept that I might know more about the technology but they almost certainly know more about their business. This is something else I can do and it does pay better. If only it was more consistant.
- -
Are you an SF Fan? Are you a Tru-Fan?
This type of thing happens in the real world ALL THE TIME
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 a particular way to support it.
I guess I didn't make my point very well. Of course there is nothing out there that is exactly like programming. No matter what examples people could possibly come up with, you can knock holes in it.
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 some common elements, then you aren't looking hard enough. (Or, more likely, you are looking too hard) Remember, they don't call them generalizations for nothing.
...are like $#@holes. Everyone has one, and they all stink. So I agree with this critique.
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.
Farewell! It's been a fine buncha years!
April 1 It's a great book; I've never been comfortable with the Art vs Science camps in software development. Calling it a craft opens up a whole new model, which I think fits much better.
One of the McCabe tools (McCabe Reengineer) already does this. It is an easy way to quickly pick out areas of great complexity in your system and then focus your efforts there. While loops, if statements and case statments stick out in my mind as being quite recognizable. However, it doesn't do anything at all to give you information about what the program _does_. But it's a nice tool nonetheless.
If all programming tasks were as exciting as defending a small village from rapacious bandits then I'm sure you would have no trouble finding brilliant programmers. Unfortunately a lot of software is not very exciting. I find it unlikely that there is a single programmer out there that writes commission accounting systems for fun.
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.
That is the first post to mention "union" -- how the hell do you think this is "redundant"? PLEASE, if you get that one in Meta-moderation, rate it accordingly.
If all this should have a reason, we would be the last to know.
They should be using variable names like $Foo and $Bar[]!!! ;)
;)
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.
In the future, I would want to not be isolated from my friends in the Space Station.
Fucking hilarious!
My specs are always a moving target.
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.
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, under funded, impossible deadlines, etc. I'm not saying software engineering sucks less or more - just that these same problems woefully apply to others fields as well.
God help me, I was right there saying amen until you said this does not happen in the real world. I could be exceptionally unlucky, however.... (grin)
+++ UGUCAUCGUAUUUCU
A star performer is the guy or gal that when you ask about them everyone else says "Well, they are really good. But..." The 'But' will turn out to be that they don't show up exactly on time every day or they don't hang with every one else after work on Friday or some other thing that has no relationship at all to the actual work.
/. is, unfortunately, not a good criteria. Reading the 'Software Patterns' by the gang of four during their lunchbreak might be one however. Also I have written before about the 'Toilet Tank Test' which is a question you ask during job interviews: "If I were to go to your house right now, go into your bathroom and look at the magazines on top of your toilet tank, what would I find?"
Reading
The answer to the TTT is often quite revealing. If they say 'Dr. Dobbs' then you might consider hiring them on the spot. If they say 'Golf Digest', then thank them for their time. The TTT works because it is designed to show whether the person is so into software development that they think about it during their 'off' hours.
- -
Are you an SF Fan? Are you a Tru-Fan?
Short, consice and on-the-money answer to all the people who throw out the "do it for the love of it argument". I wish I could mod you +5 right now.
(the subject is flamebait and overstated, but it did get you to read this, didn't it?)
According to Peter Norvig and Greg Sullivan, 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?
To a Lisp hacker, XML is S-expressions in drag.
Ahem.
There are physical analogues to prjects comparable to software design.
Build a quality custom home...that is a equivalent scope. $US250,000 Project cost $US750,000
Multiple teams working on tight schedules...oh no the plumbers a lazy bum, but he's the best we can get, lets call him up and yell at him...oh no we have a bill from theelectrician that has an extra zero on it= $US70,000...
Trust me- its a non-trivial task.
Yes; there is a fundamental difference between engineering a project and simply doing for the love of it; that's already been stated.
Would a master/journeyman/apprentice model work...
Who knows: I sure don't.
I would GUESS that it wouldn't, because programming tends be something that is taught in universities, hence you learn a great deal in four or so years, which neatly cuts out alot of the time needed to learn a trade.
Basic trade skills take about 5 years, you are decent after 10, and you are good after 15.
That's a rule of thumb when considering the time it takes to learn a trade.
My father is at the top of his trade in our area, thats how I know these things.
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.
Helping with organizational effectiveness is our job.
"will these new Software Craftsmen also be open source advocates?"
Karma whore much?
The article has nothing to do with open source or market monopoly.
One book that is well worth the time (at least for C++ programmers) is Andrei Alexandrescu's Modern C++ Design: Generic Programming and Design Patterns Applied. He presents template implementations of some of the patterns from Design Patterns. Patterns are a level of abstraction above what we used to express directly in code. That may be changing. And the code is available as the Loki library.
The net will not be what we demand, but what we make it. Build it well.
If I didn't love it, I could've sold my house (oddly enough given the slump, Silicon Valley house prices haven't dropped much), gone somewhere else, and lived off the equity for a couple of years til I found something else to do.
Even programs that look tedious on the outside may have challenging algorithms on the inside.
...this article.
I certainly agree that a small team of talented developers are more productive than horde of average programmer. What I'm looking for in his book is some hard research on why this works better, some real world cases and some partical advice on how to make this work better. I find little of these in this book. Instead the author is just self absorbed in his craftsman analogy. The main theme: a bunch of apprentices would work with a craftsman to create quality product that the craftsman would personally sign off. That's a way too simplistic idea to improve software development by putting people in the apprentice-journeymen-craftsman role.
Big regret to have spent money and time on this book.
Ok, so you say we all know how to software engineer, but I've been studying the classica paradigms and none of them are truly "perfect" like you so claim.
Even ideas as old as the spiral model have proven to be ineffective at one level or another.
The only "software engineering" that seems to have been perfected with the is the fact that if you do the same damn program for 20 years you're bound to get better at it. NASA is the classical (and really only) example of CMU's Capability Maturity Model at work. But how much does less than a MB of flight control software change in 40 years? Yeah, they're good at what they do and can predict errors with frightening accuracy because they've been doing the same program over and over again longer than anyone else.
What we need is a paradigm that works for a unique problem the FIRST time around. Not the 30th. Maybe your "old school" software engineering works in some "old school" industry you work in, but I think nearly every software engineering expert would agree that you're pulling this information out of your ass.
writing a bad article or book can happen, but slashdot pointing and drawing attention for such publication is just lame.
I've noticed that the just about all of the last four or five times that i've seen slashdot post a book review, someone has posted a comment complaining "why is it that all the book reviews on this site are always glowingly positive?"
Now, for once, Slashdot is posting a book review where the reviewer didn't actually like the book, and we have someone complaining about Slashdot posting a negative review. Wheeee..
This site is frequented by programmers, and some of them might have considered buying this book had they just run across it in a store. Now, they will think twice before buying it, and will have clear logical reasons for doing so. Slashdot has served its purpose here, it seems to me. What is it that bothers you about this, that Pete McBreen will have his self-esteem hurt?
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
... it would be the Winchester Mystery House in San Jose. It has stairs that just dead end, doors that go nowhere, and unfinished rooms. This crazy old lady uses her vast amounts of money to pay carpenters to build a house for her. So, they turned a 6 room country farmhouse into a weird, rambling mansion. That old farmhouse is still in there at the center of the mansion, surrounded by hundreds of useless rooms so you could barely recognize which rooms were original.
The carpenters had their pet projects, and some of the carpenters were obviously still in the apprentice phase. If the old lady didn't like how something turned out, she would just fire the carpenter on the spot, and hire somebody else. No wonder lots of those special projects never got finished. There was no architect, just low skill carpenters banging on nails.
I have actually worked on a software project like this. It was thoroughly unmaintainable, with much of written be people who did not understand basic software design principles. A manager fired some guy just because the software crashed when the manager used it. So, the manager had to hire somebody else to replace him. No wonder there was so much unfinished work in that software.
No design documents, no unit tests, no overall design, no modularity, and nothing was easily reused. There was no architect, just coders banging on keyboards. The core parts of the software have been rewritten so many times, and added onto so many times that you would never recognize the original code.
I am glad I don't work there anymore. It was a nightmare job for reasons besides the code.
On the types of projects where it happens "ALL THE TIME" (e.g., Boston's Big Dig), massive cost overruns are also the norm.
If a person makes a typo, he is obviously not re-reading what he wrote. That suggests he didn't care enough about the item to proof it.
However, with bad spelling, the individual may not realize that the word is wrong, and may in fact have spent a lot of time pouring over the text.
So, if you aren't going to pardon bad spelling, you CERTAINLY shouldn't pardon typos. However, both are generally catchable by spell checkers, so an argument could be made that neither are pardonable.
Personally, I don't make that big a deal about either, unless they give me a hard time about it first... Or unless it is too frequent.
I really cannot say this differently: I don't know if I could do a good review, but I know this one is flawed.
First, as the book's author points out, "software engineering couldn't accept a great number of software reviews". I agree with this.
This is a basic concept in engineering that reviewer seems to ignore: you have to be cost-conscious, sometimes you don't control things because it's too expensive.
Craftmanship, OTOH, is about learning. Try to convince your boss, in a software engineering company, that you must spend money just so that *you* learn.
Unless you're in a big "family" company (like IBM, e.g.), it won't happen. Cost rules. The whole "software engineering" idea is based on cost, from a management POV.
From the review, I get that the book may be good, but the reviewer has yet to learn some facts of life.
Just MHO.
I saw the same thing. Two Electrical Contracting firms, A and B were working on the same site. A was an army of cheap, nonunion workers in rapid motion. The average age was probably 26. B was a bunch of mostly overweight middle-aged union electricians. I rarely saw B do any work - they were usually clustered around their plan table taking notes on yellow legal pads. When they did move, it was at the rate of divers on the ocean's floor. And yet, week by week their project progressed rapidly. "A", meanwhile had numerous cases of ripping out work that was not code compliant or was based on a misreading of the plans.
All software used to be this way.
In fact, games are no longer this way, or at least, it's not the profitable way.
Games need to use libraries, need to have engines that can be brought forward instead of thrown out.
In the old days the need to optimize for slow machines was a big pressure, you didn't have a general purpose 3D engine, you had something that produced a picture and underneath was really a bunch of special optimization tricks you didn't want to bring forward.
Now, the natural progression of reuse is entering the game industry. Look how well the Sims is doing, partially because they can release the Date Pack (or whatever) and improve their system instead of replace it.
and yes, I worked in the game industry (network focussed) for over 6 years.
-pyrrho
This was one of the text books for my software engineering class. It's a really entertaining read, actually. It's engaging like no other text book is, and it makes you think about quality. It also makes you (or at least me) think about the school system, and whether or not a classroom environment or an apprenticeship-type environment is the way to learn.
The difference between this approach and others is just like the difference between Linux and Windows. Windows might look real nice, but it's bloated and not completely quality-built. Linux may have it's pains (depending on distro), but it's there and it's a solid and well-crafted foundation which will grow into the great house we're all looking for.
Ponder this:
It's true that in most cases your clients and buyers won't value quality and won't pay more for it. But, what if building a quality product was cheaper and faster than building a buggy one?
Fh
Ps: More about this in Tom de Marco's classic Peopleware.
50% of people claiming to be programmers are merely the most computer-savvy person in their immediate clique. They don't have the skills or experience to work on a real project. If you work at Starbucks but have a 300-line Perl script on your Linux "box" at home that downloads the weather report, you are not a programmer. If you have a Geocities web site with a CGI page counter, you are not a programmer, even if your grandma or co-workers at Kinkos can't even do that. Recognize these clowns by their goatees and black trenchcoats. Large herds are often in evidence at Fry's on weekends: look in the video card section.
25% of people claiming to be programmers just chatter about Java and buy books and download the latest Java crap, but can't actually get anything to compile or run because their CLASSPATH is wrong. When they aren't talking about Java they're working on their own blogging program because none of the 42,000 blogging tools already written can do all of the things they need it to do. I suspect that these dorks also masturbate while playing Everquest. The most they can hope for is to get their fat face on the cover of a 900-page Wrox book.
5% are the same as the Java dorks, but to be different they advocate an obscure language and act like everyone else is clueless. These people are also prone to excessive facial and body piercing. This group includes masochists who insist on doing everything with emacs and shell scripts. Often hard-core open source advocates who work at universities, Richard Stallman is their hero.
10% of people claiming to be programmers learned some COBOL or Fortran back in college, and now lurk in the ventilation ducts of big companies and government agencies. They often regale co-workers with Y2K war stories and anecdotes about punch cards. These are the ones you see at Fry's buying the DCOM books and Novell certification guides from the sale bin. Colorful suspenders and big beards are the style. Jerry Pournelle is the textbook example of this group.
That leaves 10% who don't suck. 10% who don't go around telling everyone they know how they can't realize their dream because no current computer is powerful enough for their unique vision of online role-playing. 10% who actually know what a pointer is from experience, rather than from articles about how C++ sucks. 10% who don't pretend to be musicians or skateboarders because they are secure with their programming skills. 10% who don't wear all black clothes or ironic thrift store garb. 10% who don't have a nervous breakdown if they have to use Window$.
QED.
-1, Funny. Well done, sir!
I've worked on many projects in the last 20years, some went very badly, some really well, some big military projects some small for commercial industry, some hobby, some finance some realtime etc etc.
I think at this point I can safely say I see people who thinks they're software developers and those who *know* they're software developers. I've worked with both types. I'd say the "real" ones are those who've worked on a largish project (say a few man years) at least once from initial specification to design to coding to testing to deployment to maintenance/support - and done this all successfully. I'm staggered at the number of people who somehow think that if they coded someone else's design then they too can design code, or who wrote function specs who then think they can design code, or who can write wonderful design docs but can't code. Some people bullshit very well to cover their asses and get high pay and more senior positions, but the real software developers see through the crap. If you're in doubt look at something they did themselves from the ground up, look at how it works and look at the code. I don't care if it was written on weekends or took 2 weeks to do what should take 2 days (or visa versa). The truth is in the src code *and* the final running software (because I've seen programs that run that are a nightmare under the hood).
And then some (many?) people think they're good and they're not. What can I say? That's the way in all industries. I was lucky enough to have my first programming job at a company called Software Craftsmen Pty Ltd back in the early 80s and they lived by the craftsmen ethic. In my general experience maybe one in 10 software developers is a craftsman and maybe 6 or 7 out of 10 think they are. The coders in a project with the courage perceive the truth and know who does the real work and who's opinion is worth seeking can still do good work themselves, but chances are they'll be in the same job and company in 5 years whereas the real developers would have moved on or up.
my 2 cents
pithy comment
Mother of God, pray for us now and at the hour of our death...
The terror from "Unmaintainable Code" is so utter and complete I doubt I'll sleep for the next three nights...
To that land where the rivers are made of honey, were it nevers rains, were there are no badies and were the projects' requirments never change!
IANAL but write like a drunk one.
Because there was also another Samurai (played by him masterfully) that faked his way to Samuraihood because he was just an impostor, althoug a brave one. I think 90% of programmers are like this Samurai but vehemently claim to be like the others.
People, get of your fat a@@es and rent and watch this movie.
IANAL but write like a drunk one.
My fave is this one. Damn, the link's broken, try this instead.
Preach it bruthuh.
I read the review and all the 3+ comments, what it made me think of constantly was gunsmithing. Specifically, pistolsmithing and the 1911.
There are dozens of manufacturers of complete 1911s, raw frames and slides, barrels, and the various small parts. Quality ranges from total junk to family heirloom/museum showpiece. And you could say that what seperates the men from the boys so to speak, is the difference between engineering and craftsmanship.
If you look at the big names in the commodity 1911 space, about $600-$800, you'll find usually servicable pistols that get the job done most of the time. A Kimber, Springfield, or Dan Wesson will generally work, but not be too pretty. Blued, nickeled, or chromed parts on stainless guns. Uneven frame/slide/ejector/extractor blending at the rear of the slide. Mediocre slide/frame fit. Impropertly tensioned extractors. Factory magazines that don't work. Burrs on feed ramps or sear noses. Grip safeties that are fit poorly or not at all. Polymer and metal-injection-molded parts.
Some of these flaws are cosmetic, some are functional. Some are showstoppers on occasion, most are trivial or nitpicky. But they are flaws nonetheless, and any mass-production 1911 is going to have them.
Move up the price ladder a bit and you get your STIs, Valtros Les Baers, Rock Rivers, and Wilson Combats. Now these are some damn fine 1911s, but they're still production guns. They're basically hand built, with great slide/frame fits, no burrs, polished ramps and throated barrels, blended grip safeties, etc etc etc. And they'll cost you $1000-$2000. However, they are still production guns that are bought off the shelf. If they don't make what you want, you have to go elsewhere, or have the modifications done afterwards.
The real quality is in ground-up hand-built guns, from the likes of Dane Burns, Ted Yost, Ned Christiansen, Teddy Jacobson, Cylinder & Slide, Kodiak Precision, Strayer-Voight Infinity, etc. From $2500 to $6000 and up, you get exactly what you want, built by hand from scratch, using exactly the parts you want, and achieving exactly the level of perfection you're willing to pay for. And wait for, as many of these 'smiths and shops have waiting lists measured in years. These are the guns built by craftsmen.
What all this boils down to is the classic dilemma, do it Right, Cheap, Quick: pick two. Kimbers and Springfields are available anywhere for a reasonable price, but may not live up to expectations: they are Quick and Cheap. Baers and Wilsons are in stock and waiting to ship, of excellent quality, and moderately bank-breaking: they are Right and Quick. Infinity's and Burns Custom's approach perfection, will last a lifetime, and cost as much as a used pickup truck: they are two picks' worth of Right. (Incidentallly, the path to Right and Cheap is DIY'ing it.)
This is the same dilemma that's existed all along in software. Arguing for "craftsmanship" is just suggesting that you should relax your requirements on Quick and Cheap, and value Right more highly.
This is in my opinion due to the fact that the majority of decision makers are a bunch of no talent sheep that can so easily be led anywhere as long as the correct formula of superficial wrapping is applied. (You know... morons!) *My appologies to Gene Wilder*
I don't care anymore about books like these.. I write only programs i like to write.. and in the time i need.. RIGHT.. i dont work as a programmer.. because i'd quit.. programmers are the assholes in every company.. and that will never change.. I'd also quit my CS studies..Now I study E-technics and will go for hardware..
Software development is only enjoyable if you do it in your spare time..
and how good can a team's output be when it is staffed primarily with liars who claim to know every conceivable language yet fail consistently to demonstrate even the basics of algorithmic comprehension and implementation ability. VB is for many a nice glue code... it is NOT core logic and is like using MS Access as a 100 simultaneous user database.