[LUAU] Hello - My Name is Scott

[Jim Thompson]

On Mar 26, 2008, at 8:43 PM, Angela Kahealani wrote:
> Everyone wants practical solutions to problems,
> and that often requires a functional combination
> of hardware and software, so it only makes sense,
> to go solve a problem with a packaged deal..

The worst thing you can say about software is that it works.

http://smuglispweeny.blogspot.com/

I walked out of my cubicle, turned left, went up one maze turn, turned  
into the next cubicle. This was clearly a while ago, before email and  
even before I had reached the point where I would phone a guy ten feet  
away in case they were not there so I could leave voice mail.

I wanted to tell Mike that I had enhanced the julian date function he  
had shared with me so he could replace his with mine instead of the  
system growing a multiplicity of julian date functions.

Mike was another contractor on some godforsakenly dreary application  
being developed at cruising altitude in some megabank, a great guy  
always joking well and laughing about everything including his  
obsession with the real estate scheme infomercials he apparently  
watched non-stop in his free time.

I told Mike I had snazzed his function up nicely, generalizing it or  
adding some whiz-bang feature or something, and mentioned he could now  
modify his program to use the new version.

Something I need to get across to My Cherished Reader is the utter and  
profound honesty of Mike's reaction. Indeed, sufficient googling may  
well surface Mike's blog entry detailing in turn his astonishment and  
horror at what I had proposed. For when I finished there was a brief  
moment of incomprehension and then a dawning and his eyes grew wide  
and his jaw dropped and then a huge smile of wonder spread across his  
face, his palms rose in supplication for any possible justification of  
my madness and at last words came to him.

"But...but...," he stammered for effect. "My code already works!"

It was a grand moment, two solid technologists sincere in their craft  
standing face to face with not one scintilla of common ground on the  
simplest of questions.

Mike was reeling at the idea that a working module should be touched.  
He repeated his encomium ("It works!") and then with no offense  
intended and with solid good-feeling camaraderie just started laughing  
at me.

Meanwhile I knew without doubt that swapping in my version would  
likely take one minute (what's that? about sixty seconds?) and that  
application systems should be kept as simple as possible (and so not  
have two julian date functions (can you say Y2K?)).

I shrugged -- it was a small matter -- and retraced my path back to my  
cubicle before the pheromone trail could grow cold. Well, this is my  
blog, so Mike was wrong. Tilton's Law:
	• The worst thing you can say about software is that it works.
I think I can prove that with geometry: if a pile of code does not  
work it is not software, we'll talk about its merit when it works, OK?  
Therefore to say software works is to say nothing. Therefore anything  
substantive one can say about software is better than to say it works.  
QED. (That last bit is the geometry.)

So what else besides that it works can you say about software,  
especially about applications written in tall buildings? Well, unless  
one is banking on the relatively high probability that the project  
will get canceled before ever it sees light of day, the software will  
eventually be asked to do new things or to do old things differently.

So the software must not be brittle and must not have any more built- 
in assumptions than necessary and where one builds in the assumptions  
it would be nice if they were abstracted out of the core so that new  
requirements can be handled as gracefully as possible.

Note that new and changed requirements come along not just after a  
successful deployment but also during development, perhaps even more  
so because only when users see software do they realize what they  
wanted. They should do a study: I bet requirements change more just  
implementing the software than they do ever after. Brittle, inflexible  
software can be so hard to change during development that projects  
never make it out the door no matter how well the software "works" on  
the original requirements.

Reminds me of another war story. Schedule "B".

The law on tax shelters had just been changed eliminating the bogus  
write-offs those things produced and some financial establishment  
needed some contractor to write the software to generate statements  
for clients detailing exactly how badly they would be hosed by the new  
law. Apparently they had tried it in-house and the guy assigned to it  
had quit after working on it for a couple of months to no avail. Jobs  
were everywhere back then in the Eighties, why not?

God forbid I should digress: it was a fun interview, really nice group  
and nice manager. The best point was when he asked His Kennyness what  
was His greatest weakness. Neat question!

Lemme see...no...no...no... I was looking at the floor going through  
coding, debugging, DB design, and it was taking a while which I  
thought was pretty funny and I am sure they were all enjoying it but  
Ireally wanted to come up with something and then it came to me.

"Testing!" I almost yelled. "I am terrible at testing!"

Whew! Reminds me of the time I had a little team (this was before  
people realized I should just be chained to an out-of-the-way  
workstation and hosed down and thrown food as needed on big projects)  
and was assigned a junior nooby who asked me the same question about  
three times and who hated me because apparently Hell hath no fury like  
a woman gently suggested she might take notes, which was great (that  
she hated me) because she was so useless we just had her testing my  
code and believe me no software has ever been subjected to such  
merciless, sustained, and deliberate abuse as was mine. Every twenty  
or thirty minutes we would hear this triumphant rejoicing "Ha!"  
explode from her cubicle as she found another bug and imagined another  
dagger plunged between my ribs when in fact I was loving the whole  
thing because to me testing is just God and Abraham and Isaac all over  
again. Where was I? Schedule "B".

Anyway, the task went very well. The manager (another Mike) gave me a  
very clear spec and I did my usual structured architectural blah-blah- 
blah and the users were very nice and called me every once and a while  
with RFEs. Bringing me to my point.

Mike was a great guy but also button-downed and into process and told  
me not to listen to the users, make them ask him and he would tell  
them, No. So I was always very nice with the users and said I welcomed  
their thoughtful consideration and input and could barely restrain  
myself from just dashing it off right now if I could just put them on  
hold for a second and I will indeed start looking at the matter while  
it would help very much if they could just run this great idea past  
Mike, he's a bit of a stickler for protocol, terrible bother I know,  
hate to ask this of you.

OK, they would say.

Then I would put down the phone and look at the code to see what was  
needed. Oh. Scratch, scratch, poke. Done.

Then I would go into Mike's office and tell him the users had asked  
for X and he would make a face and I would say I had already made the  
change if that would affect his decision.

Mind you this did not happen because I consciously planned for change,  
I just worried about things besides whether the code worked. Simple  
architectural tidiness went straight to the business bottom line: the  
users got exactly what they needed at no extra cost to the enterprise.  
How does simple clean design make RFEs easy to handle? Tilton's Lemma:
	• Refinements to requirements cannot vary fundamentally from the  
original.
It is possible for users to say, Oh my, you have the runners running  
the bases clockwise? We wanted them going counterclockwise. It is  
notpossible for the users to come back and say, We wanted them going  
first to second base, then over to first, then to third, and then  
home. Some fundamental force of nature constrains how we can screw up  
and keeps it within a metalevel such that refinements to requirements  
will never break code all that badly.

[Keep your eyes open for the "We Can Live With the Way You Handled  
That" mind-bending illustration of the power of clean design.]

The flipside war story was in a different tall building working on a  
system so badly designed that after a certain point it pretty much  
stopped evolving at all.

I walked up to my manager and said I had an idea on how to improve  
something I was working on for her so that it could be used for other  
things.

"No, no, no," she said. "I just need this one thing working before  
Thursday's meeting so I can score one on the users. They are out to  
get us."

Ah, systems development as an act of war. The system they had  
developed was such a horror that the only thing that ever moved it  
forward was a team of very well-paid outside contractors who managed  
against all odds to add new functionality, pausing from their toils  
every several days when one of them would take a design two-by-four  
across his skull from said system and lean back and poll the others on  
how badly each felt the system hindered them, an order of magnitude  
generally being settled on as no exaggeration however often it usually  
is.

The IT department ended up with a bunker mentality lobbing back hand  
grenade code releases to suppress fire from users strafing us with  
gratuitous RFEs as the organization staggered towards collapse and  
acquisition, and it being a financial institution to no small degree  
dependent on how well it processed information I cannot help thinking  
this system was to blame.

But it did work.