Saturday, May 03, 2008

Next Software Frontier: Virtualization

Now that you know that next software frontier crosses Usability and Software Testing, what is next? Definetly virtulization.

Not so visible to general users, unless you are on Mac running your Windows in a virtual machine. For Mac users VMWare Fusion or Parallels is must have. But virtualization is making a revolution in IT "under the hood". A BlackBerry user? You are backed by virtualization!

The changes virtualization is bringing to the software are exciting. Not only does it redefine the ways we think and use computers, it redefines what computers are. In the virtual world, when you need an extra hard drive, you don't run to Best Buy: with a few clicks a new HD is at your disposal. No need to ghost a machine: take a snapshot and revert to it any time. Record the execution and play it back bit by bit. Run the machine and throw away all the changes after the session is done. Playing with new software in a sandbox of VM - isn't it cool? I hate iTune for installing bunch of crap on my PC - I isolate it in a Virtual Machine, turn on demand. Well if you are with virtualization, you got it, if not - go catch up right away.

I predict that like any big invention, after aging a bit in enterprise it will come directly to consumers. And for developers: many assumptions turn false in virtual world. What was expensive is now cheap. What was impossible is now possible. This opens a Pandora box of surprises and opportunities. Get ready.

AddThis Social Bookmark Button

Tuesday, January 29, 2008

Next Software Frontier: Software Testing

I blogged about what are the three big things to me that are the next Software Frontier. They are Usability, Software Testing, and Virtualization. I touched Usability, let's move on to Software Testing:

The higher bar on usability and quality is one part of QA challenge. The other part is testing productivity, which is falling far behind the development productivity. Over a decade, development tools improved significantly, allowing programmers to crank out massive software. The complexity grows exponentially, and so does the demand for testing. But the testing productivity today only grows linearly by throw more bodies, or brains, if you’re lucky to find them. Demand is high, but supply of skilled and motivated testers are short.

The industry is still looking for answers. Time is one: wait till generation of monkey testers will pass away and a new generation of trained passionate and well-paid test engineers will come to replace them. Those who don’t have patience are looking at improving the quality in the Dev part of the house. Speaking strongly: if developers make more crap then the testers can handle, why don’t they just stop shitting and clean up? Do some [unit]testing? Go for code coverage? Take up test automation? Yeah, more quality in, more quality out. But here we often face resistance. Some old programmers habits have to die may be only with their owners.

The last one, Virtualization, is not that obvious. Stay tuned, I will come to it in the next post.

AddThis Social Bookmark Button

Monday, January 28, 2008

Next Software Frontier: Usability, Software Testing, and Virtualization

What is the next big thing? The New Year is a good time to re-ask this question. In my mind, the Software Frontier 2008 is crossing the points of Usability, Software Testing, and Virtualization.

Why so? Today I cover Usability.
The driving factor #1: computers are fully adopted by the late majority of general public. Your mom and grand mom have computers now. Unlike the early kids, they don’t play Lego games with hardware, OS and software. They expect it to just work. How naïve! Designers haven’t yet figured doors, water faucets and light switches [1]. Now we are trying to build frustration-free software. Here comes a driving factor #2: against the odds, some companies have figured how to do it. They’ve built the software that “just works”. They made it emotionally appealing. Your mom and grand mom love it. The critical mass of good software raises the bar of expected quality and usability [2].

If your software is not there yet, you better catch up. Say you are Micro$oft, and your Vista release didn’t hit the mark: dude this year it will cost you substantial business. You are enterprise application with Motif-like interface from 80s, and customers had been still buying for the business value. Not for long!

So, focus on usability, adapt the techniques and learn to build software that “just works”, and sexy to fall in love with it.

I will follow up with Software Testing and Virtualization with the next posts.

1)Donald’s Norman “Design of Everyday Things”, a deep and fascinating reading on the design for usability, entertains a reader with hilarious examples of poor design of doors, water fascets, light switches and more.

2) The bar on visual design and usability rased even in the enterprise market, which used to be less sensitive to it. Well, users are all the same people who carry their opinions from home to work and back.

AddThis Social Bookmark Button

Saturday, January 05, 2008

Santa brought me a pleasant surprise. I got a book in my mail, witch I neither bought nor ordered. It was "Software Teamwork" by Jim Brosseau. I had a privilege to review "Software Teamwork" as a member of Addison-Wesley reviewer's panel. I am greatly enjoying the final version.

The book gives a pool of experience from a software development manager veteran. Jim steps out of the modern agile hype publications by talking about cross-cutting concerns of software development. It is practical, it is real, at times arguable, and always well structured. On my book shelf I place it next to “Dynamics of Software Development” by Jim McCarthy, “Peopleware” by DeMarco and Lister, Scott Berkun’s “The Art Of Project Management”, and books of Steve McConnell's.

Reviewing a book turned out a great experience, too. It is much more work when I expected, but the joy of looking ahead of the public at exploring the newest ideas pays off for the effort. Hopefully my tiny contribution was helpful.


My warmest congratulations to Jim with the release of his book.

AddThis Social Bookmark Button

Wednesday, December 19, 2007

XP Toronto - Last Meeting of 2007

XP toronto meeting last night was a nice cozy session with lighting talks on “Limitation of agile”. Mishkin Bertreig was talking about Agile limitations with some team dynamics. He was saying that agile is not good for individual heroes. I agree, with caution. It drives me nuts to see some religious agilists writing off not only cowboy developers but also technically competent performing professionals who are passionate about software but just aren’t much interested in talking about processes. And watch for your backbone pragmatic performing workhorse outshadowed by those long-winded agile talkers!

Alistair McKinnell presented the image of desert and made home a simple yet powerful point: agile represents a sweet spot where the software development flourishes the best. As it moves away from the sweet spot, it gets harder. But it doesn’t stop working, thought.

This point was lively illustrated by Michelle D'Souza, who shared challenges of applying agile to a dispersed open-source project.

Andrey Shulinski brought up his pain points of introducing agile to a legacy product development. There are technical pains and organizational pains. Michael Fether’s “Working Effectively with Legacy Code” covers well the technical challenges. Not much is written on organizational ones. But over past years I learned more then I care to admit on how to manage legacy project development. It is probably worth a book of materials & knowledge. Is there a demand out there? Should I start writing?

AddThis Social Bookmark Button

Wednesday, September 19, 2007

Using log4net with NUnit

If you are like myself, you want to watch the log4net debug output while running my NUnittests. How to do it?

One interesting approach is described here.

A lighter alternative to consider, that also works nicely with NUnit GUI: make your test assembly to configure and load log4net.

1) Create an Application Configuration file for the test class library.
2) Add there log4net section, configure the logger
3) Add log4net configuration attribute to your AssemblyInfo.cs:


// Load log4net logger
[assembly: log4net.Config.XmlConfigurator(
ConfigFile="MyTests.config")]

Note that I renamed the auto-generated App.config to "MyTests.conf", and set it up to copy to output directory "If newer". It is a matter of the taste: you could leave App.config, and refer to it as ConfigFile="MyTestAssemblyFullName.dll.config"

PS. Is it time to move on to MBUnit?

Labels: ,

AddThis Social Bookmark Button

Sunday, September 09, 2007

15 Minutes to Move Your Project Ahead

When working on a personal project, it is the must to effectively use small chunks of time. If you got 15 minutes, and you can use them to move the project a notch ahead, it is super and feels good. If you can not, your project is doomed. You don’t have a luxury of warming up for an hour to get into the “zone”. You don’t have the luxury of keeping your mind on the project for a few days in a raw, if you have a serious day job. All you have is 15 minutes a day, so what are you gonna do? Then giving up is not an option, get smart about spending those 15 that God gave us.

There are two keys to it. First is well crafted code. It’d better be, or the 15 minutes wasted while you struggle to remember where the things were. Invest in structure, clarity, naming and unit testing. I will say no more on this: you all know the value of well crafted code, and how to do it. We don’t always do it by the number of factors. But for the pet project you don’t have an option to slack on quality (1).

The second key is effective project management. Not a heavy duty project management to kick your own ass on your fun project. But a new type of applied 15 minutes project management.

Think of a “project binder”. It comprises the scratch pad, the back log, and the support materials. They work together:

When I sit down for 15 minutes, I open a back log and look what’s there. My mood is different as so is my energy level. I pick an item that matches my mood and energy. Code a basic design for a walking skeleton while the mind is fresh at 6.am Monday morning. Do quick research on the web while having lunch. Crank down some routine UI code on Thursday night after a hard day at work. Get some fun part for a rainy Saturday morning (2).

While I am working my 15 minutes, ideas come. Code changes, fixes, extra tests, blogs to write, design thought to incubate, reading to catch up, researches to make… It’s a lot of ideas, some good, some not so good. But 15 minutes are just too short to meaningfully sidetrack. I just jolt the ideas to the scratch notes, and keep on moving on.

When I am done, I take 16th minute to reflect on what I have done. I also write a “log line” for the session: Date, how long, and what is done. I mark it in the backlog. The scratch notes go to the “scratch notes” section; I shut the binder close and go get some life.

Once in a while, in the right mood, I spend whole 15 minutes on processing the binder. “Getting Things Done” unleashed. Start with scratch notes. Pick one: What is it? Do I need it? Any actions required? Will I do it? Decide (3). Each note makes the way to the backlog, or waist basket. Or I keep it for my references. Then it goes to the “support materials”. Then review the backlog items. Listen to your mind. Does something change? Is this item still makes sense? Any ideas triggered? Check off what is done, purge what is no longer needed, adjust old ones and and create new if they come up. Finally, go over the support materials. Same here listen to your mind, get ideas, and purge what is not longer needed.

The implementation of the “Project binder” can be hi-tech or low tech. For instance, the combination of Track and Google gives a hi-tech: Work off the Track backlog, jolt you scratch notes in “Notepad”, and append your support materials to Wiki. The flow is the same: update the backlog and parse the notes once in a while. I am working off a paper based one. It is a physical binder with three sections. In the “scratch section” there is a bunch of sticky notes, index cards, paper tear-offs, and napkins. The backlog is post-it notes stacked on several paper sheets. The support materials section keeps selected notes, design scratches, mind maps and print-outs. It looks something like this:


Scratch Notes



Backlog Page



Support Materials


After glancing at my messy project binder you might think it doesn’t look like a lot of organization. That is exactly right. It’s not too much, just enough to make 15 minutes worth what they are, and move the project ahead one notch at the time.

(1) Talking well crafted code: pet project is supposed to be fun, aren’t they? How much fun is working with crappy code?

(2) If you open the back log and nothing there, it is either of the two: a) you are done or b) you got to do planning, and this is your task for 15 minutes.

(3) Get a habit of putting the date on any funky scrawls you scribble. Date you damn napkins! Later then you stare at them, the date helps you recall what were you smoking when writing it.

Labels: , ,

AddThis Social Bookmark Button