by ·0 Comments

Children are never static. Every day brings something new. In the past couple of days, Callie’s started standing up, and has sprouted a tooth. She’s also demonstrated that she understands the word ‘No’, though she quickly forgets what it was we said ‘No’ about. Each day when I come home from work, I get to figure out what it is that my kids have done and have learned that day. Cora usually tries to tell me something, and I then get to filter out what she’s actually done today, and what her brain’s churned over in the day to come up with a neat story for Mommy. Then the fun is to try to trace back the ideas she’s had to what might have sparked them – did she see something on TV? In a book? Did she and Daddy see something while they were out? Or is this something that’s percolating from a previous day or discussion? Tonight’s key phrase was ‘See you later, crocodile’. Obviously a cross between ‘See you later, alligator’ and ‘In a while, crocodile’ – phrases we often say to her as one or the other of us is headed out that she’s trying to appropriate herself. Really cute to see her trying it out. Then when I was putting Callie to bed, I got a big ol’ baby smooch, smack on my nose. She stretched her little body up and planted one on me, and then gave a big baby smile.

It’s this kind of stuff – the everyday excitements of what they’ve learned or done, the cute phrases, the smooches and hugs they plant on me, plus the bedtime snuggles, plus little heads peeking out the window to wave goodbye as I go to work, plus a hundred other things – that make me so darn glad to get to be their mom.

by ·0 Comments

In my hunts for formats for lessons learned documents, I ran across the following conference listing on the Project Management Institute’s website:

Five Lessons Learned From the Memoirs of Wile E. Coyote, by Kelly R. Slone.

Looks like a looney kind of session, if you ask me… One I’d have happily attended.

(A little bit of follow-up search found an article of the same title, written by Kelly R. Slone, in the newsletter for the Western Michigan Chapter of the PMI.)

by ·0 Comments

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.

by ·0 Comments

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.

by ·0 Comments

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.

by ·1 Comment

I was intrigued to see a new book by the guy who wrote The Millionaire Next Door, Thomas Stanley. His new book is ‘Millionaire Women Next Door’. Apparently in his research for his first set of books, he discovered that some 92% of the folks he ended up speaking with were men, and he decided that it was time to look for the millionaire women and find out what their secrets were. I haven’t read the book yet – want to check it out of the library – but according to the book review on Amazon, “While many characteristics such as frugality and simplicity of lifestyle are similar to those of their male counterparts, Stanley demonstrates that most millionaire women work harder and do better at school, in business, and in investment practices”.

So it highly amused me to see the book that Amazon is offering to pair it with in one of its ‘Buy Together’ promotions – ‘Lottery Master Guide’. So the secret of millionaire women has nothing to do with financial or business acumen or personal achievement; it’s that they know how to pick those numbers??

by ·0 Comments

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.

by ·0 Comments

‘You have 19 users in your list of banned IP addresses. ‘

You know who you are, you scum who plaster my entries with comments that say things like ‘Reduce your credit card debt’. (Hey, how about the time-honored technique of spend less than you make??) Who leave notes that suggest that I can easily enlarge parts that I don’t have, or use creams to reduce cellulite (that I unfortunately do have). All with neatly embedded URLs to take me to your product of choice. Surprisingly, Disney was actually one of the embedded URLs that came across yesterday. You’ll note that none of these things are still in the archives for my entries. I blast you into comment oblivion with the click of a mouse, and then add you to my list of folks who can never bother my site again. Count’s up to 19. And my comment phaser gun’s waiting.

by ·0 Comments

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.