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 programmers unionize.
Cretin - a powerful and flexible CD reencoder
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).
What books WOULD you recommend, if this one sucks rocks?
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
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
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.
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
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.
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
Notes of interest:
- JWR
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?
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.
my experience in corporate America is that the bit bangers APPEAR to be more productive but are actually less or even counter productive. If programmer A takes 2 hours to code a crap solution and 3 days to fix it versus the craftsman who take 2 days to do it once and do it right, programmer A looks good initially but becomes a liability.
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 top because he spends far less time debugging. Managers need to understand that simple output is an invalid measure and look more at the whole process. This is especially valid in places that do a devel cycle followed by a cleanup cycle. The friend I referenced earlier often spends the cleanup phase of projects helping the bit bangers out because he has nothing else to do.
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.
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, constantly changing requirements, and way too many incompetent coworkers.
Programming is not like building stuff in the real world. There are only so many 'features' people will ask for in a picnic table, but for a piece of software its virtually infinite. There is no perfection because no-one can agree on what perfection is for any significant application.
I'd like to respectfully disagree. There are some software houses out there that care about quality as opposed to timely release. Frankly, most game companies with AAA titles are like that. Game release dates are pushed back all the time. It's because attention to detail in a good, high quality game is generally important to a shop like BioWare or Blizzard or Epic.
:)
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 games that have failed and a lot of bad games that have done much better than they deserved. But the good games usually have the same meticulous attention to detail. Don't dump on coders that work for commercial companies. A lot of us try to do a good job.
Patterns are way too overused for my tastes. They speak to structures and themes rather than methodology. As well, they are not too useful in framing up a users requirements. Rather, they present a design lingua franca for programmers. So, while they are interesting to think about, patterns (to me) are much more of a rear-window view of design.
CrazyLegs
"Pork!!" said the Fish, and we all laughed.
I applaud your way of doing things; if I were in charge, I'd say the same thing, to a point (programs that are used rarely don't need to be perfect, IMO). However, given my experience with other programmers who take the "Go go go go go, done. Next?" approach to their assignments, I find that work gets done quickly, gets out the door and gets good money in relatively short time. Whether the expense of paying people like me (I'm a Software Analyst, I fix software problems [lots of code surfing]) is worth it in the end, I don't know, but I do stay quite busy.
Managers, deadlines, revenue, program flexibility... how are these affected by your way of doing things? What has been your experience with this?
~Dalcius
Rome wasn't burnt in a day.
Sweet, I'm not super interested in putting out there where I work as I'm kind of disgruntled as you might read from my email.
:)
As far as problems with Neverwinter Nights and Baldurs Gate. I got a little carried away, sorry. Didn't mean to harsh on your mellow. I played BG and BG2 and had a fair number of crashes. They were good roleplaying games. They weren't great software. BG1 had patches that invalidated old save files, crap like that. But I was overly harsh. Put it down to a crap ass morning due to general incompetence in the software engineering field here at ye olde game studio
As far as unreal2? The sheer monotony of the level design, ugh. It's pretty, yes, but boring as shit. I don't think Unreal (which was fun as hell)or Unreal 2 are bad as far as crashing and bugs go. I've just heard (and seen) the engine code that licensees get isn't so hot.
That being said, I stand by my comments on software engineering in the game industry. Hell, at GDC when the software engineering shit comes round, everyone is hot in the pants about windows debugging hooks! WTF? Unit testing, all of the crap, no interest. But debugging hooks, hell everyone is all over that. I don't know your project. I'm assuming you work at Bioware, I have no direct experience with anyone who works there. I can say that most studios I've been involved with aren't real pinnacles of solid engineering. And while game programmers think they're the bomb, they're usually a bit behind the curve. This is IMNSHO.
(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.
"Ah! Permit me to retort!" (Now, if only I had the Samuel Jackson look down pat, it would be perfect).
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 rational testing process, document everything well... You will likely end up with a solid project. The PROBLEM is, hardly ANYONE actually follows the principles of software engineering!!!
Companies care only about the bottom line, ok? Even Microsoft has come right out and said that fixing all the bugs in a given piece of software doesn't really matter, because most of the phone calls they receive aren't about bugs, but desired features (I'm not sure if I buy their reasoning, but some MS flack said it recently). If you pay attention to most of the things people are writing on the web about their programming practices, and if you read the articles that are being posted to programming-related magazines, AND you read between the lines a little, You'll see that they're not talking about software engineering, they're talking about hacking things together with small teams (what do you think XP is all about?).
I can't speak for everyone, but in the time I spent in private companies, this seemed to be what was going on:
1. Some manager comes up with a new Thing (tm) that they want to add to a piece of software, or maybe a new Thing (tm) that is its own tool.
2. Some developer or small group of developers is handed a "sort of" spec to follow and told "go for it, I need it by XXX".
3. The developers basically just go ahead and hack it together, figuring they'll document everything later, when they're done. Since companies are trying to penny-pinch these days, half or more of the developers are likely to be contractors, and it's likely that many will have no advanced training in computer science (hence my comment about six-month wonders).
4. After some short period of time, the Thing (tm) is presented to management. It works, because the developers have figured out a small set of test data which ought to work okay for the demo. Everyone is happy, there's lots of back-slapping, etc.
5. So, now, the managers who were at the meeting all start scheming to put their names on the project. So each one comes up with some hair-brained Thingy (tm) which they can insist the programmers include.
6. The programmers bitch about it, but they can't win, so they graft in a half-dozen Thingys (tm) and they get the project to work. Sort of. There's another demo, and more back-slapping. There may be sushi, but only for the managers. The programmers are given a dry bagel, a packet of imitation cream cheese, and a plastic knife. They go back to their cubicles and play hockey with the bagel, use the cream cheese to glue up a poster, and put the knife in their desk drawer for later.
7. Ok, now the managers are pissed because all the other managers had the same idea and everyone has their own Thingy (tm). So a round of backstabbing begins, with managers claiming that their Thingy (tm) is better than the other Thingy (tm) and that this or that Thingy (tm) should be left out because it's "not robust enough yet". This goes on for a few days, until a new list of approved and disapproved Thingy's (tm) gets sent back to the original project manager, who is now no longer the project manager but rather a gofer for the higher manager who's "taken a leadership role" in the project to puff up his resume.
8. The programmers all try to kill themselves with the plastic knives, then give up and read Slashdot for two hours while they stew about the situation. Eventually they simmer down and a round of grafting and featurectomies takes place. The programmers work late, curse th
Farewell! It's been a fine buncha years!
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.
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.
Yeah, and this is the guy who ends up dead... :-(
... 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.
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 as necessary), and also emerge completely convinced that there are zero bugs. Zero. This level is trivial for a "hello world" program, and possible for bigger programs, but unattainable past a certain size today. The 1 or 5 KLOC I was tossing around is this magic size, where something akin to a mathematical proof is still humanly possible.
OOP, Components, and so on were all invented to solve exactly this problem.
But nothing has delivered on the promise.
Don't get me wrong. The movement from spaghetti to structured significantly reduced the number of bugs in large systems, and probably from structured to OOP as well. However, the inherent complexity introduced could not be completely solved. Each object you define hid details, but also introduced risks, because the interactions between modules are still defined in fallible (and often plain vague) ways. The tough bugs in structured or OOP systems today are typically subtle interaction bugs, where one module does something just slightly unexpected by another.
I don't think you're actually disagreeing with my original point that we're not exactly at the end of the evolution of software engineering practice.
Eventually, you CAN probably work all the bugs out, but you have to have more patience than you'll find in private industry.
You are attributing bugs to economics, which may very well be true. However, absent proof I am doubting that it's possible at all to achieve zero bugs past the "magic size". Note that while open source software (which do not have the commercial pressures) are shown by some to have fewer bugs, it's not zero.
Look at the space industry. The Space Shuttle flight control, IIRC, is really two pieces of software developed to identical specs, voting in real time to decide what to do. IOW, NASA decided to pay two groups (not cheaply, either), rather than pay one group double. That indicates that they don't think even twice the money will achieve the safety afforded by an independent reimplementation.
I respect your view of the future; you seem very optimistic about it.
Here you are completely mistaken. Software engineering is creative and challenging today. The future I foresee is essentially blue collar, involving assembly more than creation. It's a step forward for the science, but I'm not sure practitioners will have as much fun. I'm personally not looking forward to that. :)