Most interesting quote so far in a book I picked up at JavaOne: “System Documentation is a Business Decision, Not a Technical One” – Agile Modeling, Scott Ambler. The gist of his statement is that writing (and then verifying and maintaining that documentation) takes time and resources that would otherwise be committed to other areas on a project. Documentation is one way of spending development resources, one which may help reduce certains kinds of project risks.

So, before you send me off to write another detailed design document or in-depth maintenance plan, think about what functionality you’re now willing to give up. In practice, what happens is that we squeeze the documentation in, churning out pages fit mostly as evidence that we’ve “done the documentation”, since payment milestones for contracts are often tied to delivery of those documents. But the net value to the customer for that document is negative, since the document doesn’t provide enough value within it to be worth the time reading it, much less the time writing and editing it.

Enjoying reading Mr. Ambler’s book (though he would have benefitted from a better editor). Enjoyed hearing him in person at JavaOne, as well. Always interesting to match a face to a name, and to hear what someone says when they’re a bit more unscripted than in a book. His Australian outback hat was a nice touch.

I’m collapsed in a bean bag chair in the Moscone Center in San Francisco at 10 pm (Pacific). It’s been a long day – sessions from 8:30 this morning, one more session that I’m waiting for (at 10:30), and then the 11:30 set of options that I’m skipping in favor of sleep. This bean bag is mighty comfortable. Wouldn’t take much for me to fall asleep here.

More blogging to come as I digest all tha I’m encountering here at JavaOne. Lots of neat technical stuff, some of it presented by better speakers than others. And, of course, there’s the whole city of San Francisco waiting outside, with all of its wonderful experiences. In the course of literally a city block, I encountered (1) a homeless guy who conversed me with about his theories of why library security officers give him such grief – discussion complete with him pulling out a copy of the NIV Bible and reading verses from Deut 23 (?) re: slaves….. (2) a drag queen / cross-dresser / transvestite (insert appropriate term – I’m not conversant enough with the differences and don’t particularly care to be educated) – this drag queen appeared to be listening discreetly to the homeless guy, though not participating in the conversation. [This all happened in StarBucks, btw, in case that puts an even weirder spin on things.] (3) And then there were the 4 (!) women carrying shopping bags from a shopping expedition from their boss, the CEO of a hospital. I had commented about what studious shoppers they seemed to be, when they informed me incredulously that this lady had bought 3 leather coats. The worse offense, it seemed to at least one of them, was that these leather coats were not suitable attire according to the dress code of the hospital. Just having spoken to the homeless guy and having passed many this week who were shivering in the chilly SF evenings, I think there were worse things to be offended about.

Something for my next employment contract: if it remains necessary for me to work at some large threshold above normal for more than 3 weeks in a row, I get an automatic bonus in the paycheck. This idea came to mind as part of the wrapup for our phase 1 deployment. This phase has been a beast – since December and up until just a few weeks ago, our whole project team was consistently wracking up work weeks in the 55 to 60 and up range. Software professionals expect that once in a while; it’s an accepted necessary evil to hit “crunch time” and work a bit harder. To do it for as long as our team did it, though, speaks of a team’s commitment to making the impossible happen, and is an expression of just how near impossible what we pulled off was. High personal cost, to us individually and to our families. Low corporate cost: there’s no financial indicator that any of this happened, since we’re all salaried. Salaried does imply a bit of leeway for the corporation, hence setting the performance bonus out after a lengthy period of overtime, rather than at the first bit. The idea is to remind somebody who runs the purse strings that this isn’t the way things should work. I’m a bit cynical: corporations learn best, I believe, when someone looks at cost versus benefit. It’s hard to quantify personal cost…. it’s a lot easier to quantify dollar cost. So it makes some amount of economic sense to make the picture clearer by assigning a dollar value to the personal impact.

I sling code for a living. Done COBOL (bleah), VB, ASP, Java, C#, ASP.NET, PHP… and there’s all the supporting stuff – SQL, JavaScript, HTML, UML, XML … The bevy of acronyms can cause your head to swim.

Today’s adventures had me crawling through SQL query execution plans and trace logs, and .NET memory profiles. Two very different application life-threatening bugs, requiring two different investigation approaches, neither of which is encompassed by all of those acronyms above. (Just because I can write SQL doesn’t necessarily mean that I usually care how SQL Server decides to execute that SQL, so long as it returns the right results. Today’s exercise in query locking, however, had me wading.)

Hours later, our project no longer looks like it has the potential to founder on the rocks of architectural weaknesses. We’ve found the bugs (or, at least, in the case of the memory leak, found the big one causing the kaboom) and corrected them with relatively little changes to the code-base. So, our testers will be happy that we didn’t need to do a total rip and replace. We’re happy that the problem is solved (?). And the system will deploy on schedule.

None of the stuff I learned and exercised today will show up neatly on my resume. The skillset recruiters look for doesn’t usually go into that level of detail – they want to see the language acronyms, the systems lifecycle buzzwords, the application domain areas. The person interviewing me may or may not have experience with this stuff themselves. But I’m a better software and systems engineer for the day… and hopefully quicker out the gate next time with an answer to the problem at hand.

We’ve got this tester named Doug. Doug’s name strikes fear in the heart of developers on the teams to which he’s assigned. He specializes in finding those boundary conditions, those way outside the scope of anything you’d expect a user to reasonably do (a reasonable user, anyway, and we all know that there are bound to be a subset of them who are unreasonable in just the code-terroristic sort of way as Doug), the ones that break systems in ugly ways.

An example from a bug report he filed today:
Entering the following search term causes the user to see
an unfriendly server error:

!@#$%^&*()`-=[]\;’,./~_+{}|:”?

Now, I’m not certain that this blogging system is going to handle that text well. Computers don’t generally like to be cursed at anymore than humans do.

Or from this bug report filed earlier:
A vendor cannot upload more than 25 Contract Mod Attachments.

Now, Doug sat there and uploaded 25 separate files to find this bug. With no special knowledge of the system to know that 25 was the magic number. For the record, I did correct that bug, but I’m not going to say what the new magic number is, except to say that it’s sufficiently higher that I’ll personally throttle Doug if I discover he’s tripped that particular boundary.

The stuff Doug discovers is key, actually. Lots of security problems in systems end up boiling down to things like this, where the system just can’t handle some data input at the boundaries of what anyone thought was reasonable. No one ever thought that a user would put in such data, and so they didn’t guard against it, and the system broke in some way that offers a hacker a chance to either directly get in, or just gather some information that lets them try another avenue of attack. For instance, if I’m not careful, the error message that the computer returns tends to be the sort that makes it easy for developers to track down sources of bugs, including database table names, code line numbers, etc. But that also gives Joe Hacker a heck of a lot of info to start with.

So, thank you, Doug, for forcing me to be a better developer. I have aspirations of writing a set of objects that do all sorts of bounds-checking, data validation, etc, and somehow plug them in an aspect-oriented kind of way so that a developer can’t neglect to apply the validations. And I think I’ll label the package something .doug.

Guess what’s missing (yet not missed) from this list of things done tonight?
* Ran 3 miles
* Went to dinner with my husband (oooh, a date!)
* Perused the magazines in the bookstore whilst we waited for the latest torrential downpour to pass by
* Cleaned the cat boxes (bleah – I’ll never own another cat)
* Picked up the basement
* Sketched out a list of things to take and things to do before our camping trip with the girls (look sometime next week for a description of success or failure, taking a 2 year old and an 8 month old tent camping)
* Edited 1 blog entry, wrote another one (this one!)
* Went to sleep at a nearly reasonable time

Give up?? Nothing about work. Nada. Nichts. Not even writing this from my work laptop – left it in my office. Left it sitting lonely in its docking station, thinking whatever thoughts lonely laptops think when they’re deprived of company. In case you’re scanning the ‘Net, little laptop, looking for something to remind you of me, I dedicate this blog entry to you, ‘puter. But I hope you start coming up with hobbies of your own, ‘puter – I’m hoping to spend a little less time on our relationship.

Bug 6619, assigned to me on my project, innocently asks, “Should prev next appear at the bottom of the list, if there is no prev or next page?” The page uses an ASP.NET DataGrid, which nicely provides me an easy way to turn on paging, which is the idea that I don’t present to you all 300 records you asked for at once, but I let you get 25 or so at a time, with buttons to traverse through the set. In this case, prev/next buttons.

Turns out, Microsoft easily grants me the capability to turn on paging and easily grants me the capability to say that the buttons should say prev or next, but doesn’t easily grant me the ability to turn off, say, the prev button if that button shouldn’t exist. It’ll happily turn off the link itself, so it “knows” there’s no previous page, but the effect of that is to just display the text ‘prev’ without a link. Attempts to update the text of those links on the fly, say to an empty string, are happily ignored by the page… Grr….

So, I start investigating other options. Turns out I can put in my own custom navigation controls, and bypass the prev/next button stuff. Great! The document that tells me how to do that says ‘One of the options on the Pager tab of the Property Builder is Show Navigation buttons’. Hmmm… option on the what tab? Not seeing that in my Properties window…. Oh, that’s because it’s only available on the Property Builder, one of those wizard things I usually avoid because they end up doing stuff for me that causes problems later. Flipping the switch there gives no obvious indication in the Properties Window, no obvious indication in the HTML code, no obvious indication in the code…. but somehow things work differently. Grrrrrrrrrr…

I’ve now spent almost an hour and a half on this bug. Microsoft, your documentation leaves much to be desired. Those of who want to do things beyond your basic behavior run into too many stumbling blocks that don’t have to be there. Don’t box me into your default behavior. Particularly don’t box me into your default behavior without giving me a big ol’ warning that this default behavior can’t be overridden in rational ways. At least spare me the time of running down those fruitless reasonable paths by pointing me in a direction: if you’d like to do X, you should consider using Y instead of our normal recommendation of Z.

Frustrated…

Woohoo! My hard drive crashed! Made for a miserable afternoon at work, but then the silver lining kicked in. Crashed hard drive means no functioning development environment. No functioning development environment means no no work tonight. No work tonight – oooh, whatever shall I do with myself? (Sleep is high on the list.)

Just a basic economics of software development question: do you ever find that the quality of your after-hours coding goes up in direct proportion (though potentially with diminishing returns) to the number of beers you’ve consumed? In the spirit of continuous software process improvement, I believe I need to test these working conditions further. Anyone willing to provide me grant money, all in the spirit of research, of course? Fair warning: my requirements for beer are a definite determining factor on the cost of this research – no Bud Light, Natty Bo, etc. I hypothesize that my code works better because I’m more relaxed and suddenly find things amusing to fix, rather than pain-in-the-neck annoying or beyond-the-level-of-frustrating to fix. Note that this is not my usual method of after-hours coding. Somehow, tonight just felt like a good evening to imbibe. More follow up analysis required, particularly as I look at the results of my coding in the light of complete and unblanching sobriety.