Quantity vs. Quality of Requirements

I have had to get better lately at writing requirements. In a recent project, there were two mistakes that came about because the requirements were not robust enough. The mistakes were caught late in development, and the problem was that the developer could not complete the requirement as stated. Ironically, it was the developer that had not thoroughly considered the requirement when agreeing to the task, and postponed all thought about it until it was too late. We had to notify the customer that we could not deliver what was agreed to.

It is well known that the requirements must be reviewed carefully with the customer to ensure their desires are well represented. The requirements must be reviewed with equal care with the entire development team, including third party contractors, to ensure that the requirements are technically feasible. Testers can bring clarity early, and developers often connect gaps in the requirements from their own familiarity with the systems.

It had not been my intention to produce requirements in a vacuum, but it worked out that way on a particular project. The third-party contractor reviewed the requirements, gave an estimate for the work and then, five months later when we finally moved to develop the project, the contractor could not deliver. It was like they threw a number out at us without considering how they might solve the problem.

So I am instituting explicit reviews to give people an opportunity to challenge the requirements. It had been my habit to distribute them and solicit comments, but that's too passive. I have to challenge people to challenge the requirements.

At the same time, I've needed to produce them faster, and so I have found myself cranking lots of words in short, focused times. This is usually at the end of the day when my goals for the day are at risk, and I need to produce. I am simply surprised how much I get done in the last forty-five minutes before I leave, but other people are winding down, and the interruptions stop, and I can sit and think.

I wish I had an office with a door, but at least I don't sit outside the men's room, where it's busy, noisy, and smelly.

Ogres Have Layers, Like Onions

I use Ubuntu on my laptop. Specifically, I use Xubuntu. I really like, but on rare occasions, I need to use Windows to get to Internet Explorer so that I can make a remote desktop connection; specifically, it's making a Terminal Services connection, and that just won't run under Linux.

In the past, I have used rdesktop on Xubuntu to connect to a Windows box on my network, but I can't use this here to cross the firewall involved. But I could then leap from my Windows box across the firewall to the desktop I desired.

I decided to cut out the middle man, sort of, and installed Windows under Sun VirtualBox on my Xubuntu laptop, and it worked great. It took the better part of a day to get all the service packs installed, but, now that it works, it's a very cool bit of technology to fire up the Windows virtual machine from this Linux laptop, and put it into full screen mode, and then use Remote Desktop from there to cross that firewall using Terminal Services.

It's a little slice of cool to put all of that together. It's one fairly amazing technology piled on top of the other. Like the layers of onions.

A Bigot's Approach to Web Development

I have mentioned (at length) that I am working on an application for Facebook, and using Dojo Toolkit for the browser interface. It works great in Firefox. I did all my development and unit testing in Firefox. Dojo Toolkit is supposed to handle the compatibilities between browsers. That's really great when it works.

I have also mentioned that the Dojo Grid does not render correctly in IE 6 or 7. Like an idiot, I never tried it until one of my Facebook friends mentioned that it doesn't work. So I have finally checked it out with IE8 and discovered, much to my horror, that the grid doesn't render at all.

I scoured the Dojo Toolkit website for clues, and I did find a couple, but nothing that applied to my situation. I'm hoping they magically release a new version but, in the meantime, I'm going to release a very different version with simpler controls. It breaks my heart a little bit, but I need to get something released.

What I've learned is that I would have been much better off paying attention to the browser of my user base (IE -- still 70%) and not the one I like (Firefox). I was bigoted; but I've got that out of my system.

The Ways of Analysis

I have a variety of project at work, and so I must use a variety of techniques in conducting my analysis. What pangs me is that not all techniques are as fun as others. Here is my rough draft list:

• New Solution
• Modify Existing Solution
  
• Implement Existing Vendor Solution
• Implement Off-The-Shelf Solution
• Implement Hosted Solution
• Modify Hosted Solution

That's fairly reasonable order in terms of fun. The most fun is to solve a problem with a brand new solution, the least fun is to request a fix or change to something completely out of your control. It's hard to make your needs known and to schedule the solution. That's just an all around pain.

When you're solving a problem that, at least where you work, has not yet been solved, you have the thrill of invention combined with the discovery of a business domain. You are Edison and Magellan, rolled into one. If you're very lucky, you get to be Patton, as well, and lead the troops to victory.

Of course, the "solution" itself has a range of fun-ness. Some tiny, pain-in-the-butt utilities are no fun when only two people use it, and they don't even like it; it's difficult to get those modified when everyone would rather ignore it, and use something else.

I happen to be working in the realm of content management at the moment, so that's a reasonably fun set of solutions. I ain't complaining. If I were to complain, it'd be because I'm not able to use my Cooper training at the moment, or to program in Python.

Command Line Blogging

Occasionally, my creative side and my technical side complement each other. I am preparing to write a long, long story—a work of fiction. I intend on serializing the story on a blog, but I don't want to sign into Blogger.com and leave all the original work there, in its system. It also doesn't feel right to just cut and paste (although, really, it would be simple enough). I want to have the text on my Ubuntu laptop where I can be responsible for it.

My first thought was to post the blog entries directly from VIM, but the nice person who figured out how to do it did not post his work anywhere that I can find it. It really used Python to talk to google and blogger, which was fine. There is also a version that uses Ruby in a similar fashion, but I don't want to get started with Ruby at this moment.

So I found out that there is a Python recipe for talking to blogger, and I may need to wrap that in some command line options, but I'll use that to post entries to Blogger.com. I can even do it from vim with the good old bang (!).

Blog Post From the Desktop

For a variety of reasons, I am interested in posting to this blog from the desktop. Ideally, I'd like to create text files that I store on my hard drive, then post them to Blogger.

I looked at vim-blogger, but it requires VIM with Python compiled into it (I suppose I should just do that and quit goofing around).

I was very hopeful for TomBoy with its Blogpost plugin, but it has not been able to connect to Blogger.

Any ideas appreciated.

Increasing Timeouts

I made a silly mistake the other day with a database query. On my test system, it took a rather long time. Three Minutes. Three minutes are an eternity if you're waiting for a database query. Minutes give you time to think that your entire career has been a mistake, and you should have entered the priesthood. Three minutes gives you enough time to mentally undress everyone in your cubicle isle, and then you wish you'd stayed in the priesthood fantasy.

In spite of the long run time for this query, it actually seemed reasonable to me, so I moved it into my production system. I thought that, because the production hardware is more robust than the test system, it would run faster. I was wrong. In fact, it took longer. In fact, it took ten minutes and only stopped because of the timeout setting on the web server running database queries. In ten minutes, if you're waiting for a database query, you can question the validity of the U.S. Constitution, and wonder if the Founding Fathers, some of them slave owners, drunkards, or adulterers, were reasonable human beings with a legitimate right to create a new form of government. But ten minutes is also long enough to realize that, given similar circumstances, you'd probably own slaves, drink too much if only to avoid the diseased and putrid water, and sleep with anything that wanted to sleep with you, so maybe the separation of powers in the federal government in fine just the way it is, especially due process and double jeopardy. (You never know when you might incriminate yourself after an arrest, and risk standing trial twice for murder.)

I decided to consider the query once more. It was, in fact, three queries in parallel, so I ran each one separately and found the offending code. I compared it to the others that ran so much faster, and realized I was missing one of the where clauses to limit the amount of data. This query runs against a single table with sixty million records in it. I added the clause and, lo and behold, the query ran in a single second.

I am somewhat embarrassed at the speed improvement. This is a hey-your-fly-is-open kind of moment, and oh by the way, I'm not wearing underwear. I'll get past it.

I went to make coffee after that, and I had to brew a fresh pot. It takes four minutes to brew fresh coffee. Four minutes! You know what I can consider in four minutes? I questioned the Emancipation Proclamation, the Declaration of Independence, and the Magna Carta. But my reasoning will be revealed in another post.