Infrastructure Fix    [ random/ ]

Finally!  Took a day off from preparing for the (Advanced Architecture and Design) course I'm hosting next week, and spent the time getting my local infrastructure back on its feet after a breakdown some weeks ago.  Basically the LAN server died... motherboard or CPU. Suddenly we realised just how much we've come to depend on that little machine!  DNS caching, plus names for all the machine on our farm-LAN1, HTTP proxy, local Subversion server, file-share, music streaming, and not to mention supplying the base-infrastructure for some Jini services that come and go as we play around with Jini and JavaSpaces.

So now that we've beefed-up the CPU and disk a bit, it was "just" a case of getting all the bits of server software installed and cleanly configured. Nothing difficult, but it all takes time! Especially when you're a bit.... fastidious?... about getting the config "right", as opposed to "just poking things until they work". I truly despise "voodoo config" where people don't really make the effort to understand the impact and effects of what they're doing, and fuck it up royally as a result.  "Oh, well, I'll install mod_disk_cache and mod_mem_cache... after all, two caches must be better than one, mustn't they?"  Ding!  You Do Not Win The Lounge Suite!

Well, its been fun! And finally I can forget all about it again until the next hardware failure. The only thing I really would like to achieve is to get the server quiet2, and get its power-consumption way, way down!  And maybe have a few more tiny-little servers...

[1] The term "server farm" takes on a whole new significance ;-)

[2] Yeah, I'm a complete arsehole about noise. I really, really, really hate noise...

10.Sep.08  3:11 PM, SAST | Words (282) | 0 Comments | 0 Trackbacks
reddit!

Brain Delayed - In Transit    [ random/ ]

On my way down to Cape Town -- yet again -- for a Java Intro course -- yet again...

On arrival at the checking-desk, get told that I'm not booked to go to Cape Town, but am eventually found to be on my way to George from Cape Town. Returning to Cape Town on Friday. Wow! What happened here? OK, so off to the booking office where I have to fork out an extra R700 to cover the ticket change. Fortunately the SAA staff at George and I know each other by first name. (As a result I seldom have to produce ID to check in -- most of the staff can ID me by sight. Beat that for personal service! ;-)

Sudden thought: Let's check the car rental reservation. Sure enough! I'm booked to pick up a car in George. Get that one changed. Things are so screwed up at this point that I called the B&B where I'm allegedly booked to stay in CT. Yes, indeed, they DO have a reservation for me.

WTF was somebody at the travel agency thinking? This guy is going to fly from Cape Town to George, pick up a car there, and then stay 5 nights in Cape Town before reversing the journey?

Now I only have to waste an extra hour-and-a-half in the airport. I just love hanging about in airports, don't you?

16.Aug.08  7:04 AM, SAST | Words (228) |
reddit!

Software Estimation Considered Harmful    [ random/ ]

problem

"So how long do you think it's going to take?"

We've all been asked the question a thousand times and more. Project Managers, Client Liaison, Salespeople, Marketing Managers,... they all want to know. And we, like sheep, like the suckers we are, because we try to please (you try, too, please!) suck hard on our spacebar-calloused thumbs, and guess.

"I guess a couple of days."

"A week."

"Three months."

"A year; maybe 14 months."

Nobody really trusts those really long guesses, though, so that's where the project management experts get involved, break the task down into itty, tiny bitty little bits, parallelise them, ALAP, ASAP, lead and lag. And then we all sit down around a table, and for each and every one of the itty tiny bitty bits the project manager asks the dreaded question.

"So how long do you think that one's going to take?"

The Real Answer, the Truest Truth, is, "I don't know." Perhaps a tiny voice deep inside our soul cries out, "I don't care! It is going to take as long as it takes." But for mysterious reasons all tangled up in our wetware, all tied up in the social hierarchy dynamics of the human ape and those twisty strand of ribonucleic acid in our hardware, "I don't know" marks me as less-than-competent. And "I don't care" is career limiting; "Not a team player. Fails to identify with the organisations goals and ethos."

So we guess, and we guess, and we guess again. And we're (almost) always wrong!

For 50 years we, as a craft, as an industry, have been guessing wrong. For 50 years our projects have mostly finished "late", and we keep wondering "Why?" Books have been written, Methodologies developed, PhDs awarded, Management Disciplines imposed and entire Consulting Industries built on the premise that it is ''possible'' to estimate software effort better than we presently do. Or, if we can't estimate better, then we can manage the estimation risk better. Or the process. Or those pesky damn programmers.

All in vain. The projects keep coming in late.

where it all comes from

How did this abysmal state come about?

I think it is rooted back in the 1950's, when the first Big Software projects were undertaken, most notably by the US military. Quite naturally they applied the project management strategies that have worked for them since time beyond time. Strategies that have successfully built forts, dug moats, laid siege to cities and moved large numbers of soldiers across continents and seas. The trouble is that those are extremely well understood problems that have been solved thousands -- millions -- of times, ever since Akkad invaded Ur. For such classes of problems, estimates of time and effort are pretty reliable. If you're a logistics planner, an army engineer, you know, from loads of practice and handbooks distilling five thousand years of experience, just how long it takes for a boatload of soldiers to move a given distance, and just how much food, water and fuel they need along the way.

"Where there are in the field a thousand swift chariots, ten thousand heavy chariots, and a hundred thousand mail-clad soldiers, with provisions enough to carry them a thousand ''li'', the expenditure at home, including entertainment of guests, small items such as glue and paint, and sums spent on chariots and armour, will reach the total of a thousand ounces of silver per day."
-- Sun Tzu, ''The Art of War''

It is an extremely well understood problem domain!

Software development is a different sort of beast. It's all new to us. Amost every problem has never been tackled in its entirety before. I don't claim that software development is unique in this; I am pretty sure that developers of new aircraft, ship engines, new forms of bridges, all face the same problems as software development. What -- perhaps -- distinguishes software development is that it's all new every time! We never get to repeat our past developments. If we were repeating -- exactly -- repeat-developing a requirement -- in every detail -- we would already have the code and we'd have no need to write anything! And if there's one thing I've learned about developers, its that we -- most of us -- hate doing the same thing twice! It's probably a function of our predisposition towards ADD/ADHD.

all change

But, no! In truth there are always differences between the Systems That Have Gone Before, and the Systems We're Developing Now. Even if you've developed interface to a dozen payment gateways, 100 gets you 1 that the next payment gateway has some unique characteristics all its own. Or perhaps some key technology has undergone a significant change in the last few years. Or some new tech has crept into the picture. "Our service is provided through a RESTful API"...

Then, too, how do you account for the Buggerance Factor. Murphy's Law. The simple fact that even the simplest piece of software depends on a ''huge'' number of other bits'n'pieces being in exactly the right places, configured exactly right, at exactly the right time?

I should not have had to spend an hour this morning tracking down the fact that a key library -- a jarfile that should always exist in a standard, accessible place -- had mysteriously been Taken Up. Vaporised. Gone. Perhaps my disk is going flaky? It shouldn't have happened. I should not have wasted an hour figuring out why the application wouldn't run. But I did.

I should not have spent a morning last week discovering that, despite the Vendor's persuasive assurances to the contrary, the version 8.2 driver does emphatically not work properly with the version 8.1 server. Let us not even ask the question, "Who installed the 8.2 driver?" A fruitless waste of time, energy and stress hormones.

How the hell do you predict that particular morning and figure it into your time and effort estimate? Or the half-day spent figuring out that there's a bug in a key data-access library you're using (and it's not your choice that mandated its use, but some arbitrary "policy".) And then another hour figuring out a way to work around the bug. Just how exactly, when you're Project Planning some 4 months ahead of a frustrating and unproductive morning, do you predict those?

You just blew your estimate.

managing estimation risk

I am well aware of various approaches to software development that try to futz around the problem -- some of them with some marginal success -- by giving up the idea of a project being "finished". But nobody seems willing to confront the central problem head-on.

Estimating "How Long It Will Take" is a Broken Idea.

Like the drunk looking for his spectacles under the streetlight "Because that's where I can see to look for them" we keep searching for ways to make estimation more accurate, more reliable, more amenable to conventional management thinking. What we really need to do is screw our courage to the sticking point, and accept that there is, really, honestly, truly, no alternative:

We must completely abandon the whole concept that software effort is amenable to estimation at all.

call to arms

Give up the crutch!

The next time -- and every time after that -- that someone asks you "So how long do you figure that's going to take?" -- "So when do you think we can go live?" -- Just Say No!

Just say, "It will take as long as it takes."

I guarantee you some excitement in the short minutes immediately following, but let go of your fear! Immediately you will find yourself skulling in the calm pond of assurance and truth that lies beyond the fear. Live and enjoy this Truth, for it will set you free. If other people want and need to make deadline commitments, let them be the ones to suck their thumbs, making up fantasies and lies. Do not allow them to push that responsibility onto you. Don't allow them to turn you into the liar. Just tell them,

It takes as long as it takes. It always does, anyway!

Technorati Tags: , , , ,

23.Apr.08  11:56 AM, SAST | Words (1324) | 0 Comments | 0 Trackbacks
reddit!

Bad. Punctuation,    [ random/ ]

Tripped across this little quote on /. this morning:
A Linux machine! Because a 486 is a terrible thing to waste! -- Joe Sloan, jjs@wintermute.ucr.edu
Alas, I can clearly see that somebody screwed-up the punctuation.  Surely that should read
A Linux machine! Because a 486 is a terrible thing. To waste!

15.Apr.08  9:02 AM, SAST | Words (51) | 0 Trackbacks
reddit!