a formula for failure (or an expensive redesign)

If

'Premature optimization is the root of all evil.'

then

'Premature automation is the propagator of many evils.'

else

'Failure to optimize is the abyss.'

end;

Miracle Åben Verden and other presentation news

I have several presentations coming up, but due to a dramatic set of circumstances in Denmark, I will be posting about them in reverse order. Miracle OpenWorld has been renamed due to possible 'mark' infringements on the term 'OpenWorld'.

Therefore, I am pleased to announce that I will be giving a presentation on 'Measuring for Robust Performance' in April at Miracle Åben Verden!

You can hear all about the conference from Anette and Mogens, plus you can see the very official looking message from Oracle.

.... although when lawyers skip the word 'trade' and refer to a 'mark', I wonder if they really believe their client has a claim to the term. Highly questionable :)

I will also be presenting at the following conferences, continuing on the reverse order theme:

Southeastern Oracle Users Conference

February 23rd - 24th

Rocky Mountain Oracle Users Group Training Days

February 16th - 17th

Northern California Oracle Users Group Winter Conference

February 11th

The locations are geographically diverse so I am staying with the same presentation subject, but I'll change things up a bit just in case anyone does decide to attend more than one showing. I suppose I could offer repeat attendees a beer for each prior version they've witnessed just to ensure they're happy with their choice to attend again.

I'd offer the NoCOUG attendees a beer for each showing they planned to attend, but I'd have to take some kind of collateral on that deal.

it didn't work ...

I did manage to publish a link to this blog post, 'Releasing early is not always good? Heresy!' at about 3:00 am on Jan 1st. The plan was that I'd close out 2009 by getting the last few posts related to Agile design off of my mind so I could start 2010 ready to return my focus to measurement.

Fail.

I woke up late that morning, drank my coffee and thought about problems in the design and development process on various projects most of the day. Yuck. So at the end of the day, I pulled the post, resolved to focus on measurement anyway but recognized that I'm not going to be able to leave design process methodologies in 2009 after all.

Here's the issue: I see process problems within various projects and teams all around me. Some of those problems seem to be related to a misuse/misapplication of the Agile methodology. On the flip side, some of the great things that are occurring are related to the successful use of the very same concepts. I keep looking for the common and missing threads across these projects, but it's a bigger data set than I expected. I thought (hoped) is was people related because if I narrowed it down to a few individuals that had it wrong, that would have been the easiest answer. Then I considered schedule, management, project size, project complexity, commitment to process or lack thereof. And the answer was that it could be any or all of the above, depending on the specific case. So no easy answers and no leaving the questions behind.

I do see one common thread and it's similar to the primary topic I want to address in the measurement tools discussions. Sometimes we all use a good tool in the wrong way. Or we use a good tool for the wrong problem. I'm not alone in my distractibility: the IT industry as a whole suffers from adhd. We all tend to jump into the latest new tool/methodology, decide that one tool is the holy grail of computing and use it/abuse it to excess, applying it to every project and product regardless of its suitability for such application. Then the next new thing comes along, and we leave the last grail behind, failing to carry forward the lessons learned and the components of the tool that were actually beneficial.

Any good tool applied in the wrong way will fail to perform as expected. The real drawback is that someone's choice to use the tool incorrectly sometimes tarnishes the reputation of a very good tool. I think this is what has happened with Agile: it's been applied inappropriately in some cases and ineffectively, without proper planning and thought, in others. This can also happen when we chose our tools to measure performance: use a good tool for the wrong kind of system or problem, and the results will be less than hoped for. This doesn't mean we should stop experimenting with new tools and new uses of old tools, but we need to keep our eyes wide open as we do so.

I had an interesting discussion with a systems engineer recently. He was somewhat dismayed at the prospect of having to demonstrate and prove his conclusions to our customer in advance. He had researched and documented his findings, and wanted moved on to implementation without having to prove what he saw as obvious. According to him, it was the research, documentation and attention to detail that made one an engineer. I disagreed. Engineers do tend to research, analyze and document in depth, but every engineer I've ever met cannot resist experimenting and trying to use a tool in some new unheard of way, just to see what will happen. And if it works, they will continue to use it even if the tool wasn't originally designed for that purpose.

Engineers will also break things just to see if it can be done and what will happen. Testing to destruction is a game for them, as I learned back in 1997 when my client-server database had 150 engineer clients. Learning to break a tool is highly educational, as is learning how to prevent that break. My solution to stop the engineers from breaking the client workstations was a cabinet full of pre-imaged drives. If they broke their workstation software, I pulled the old drive out, bolted the new one in and took the old one with me so I could re-image it and stick it in the cabinet for the next failure. That minimized the tampering a bit. It didn't stop it entirely, but the guys made sure any files they needed on that drive were backed up, or they made sure they knew how to undo the changes they made. And I learned how to minimize the impact of their testing on my time. The point is I've never met an engineer that didn't prove his assertions. We're usually smart enough after a few 'incidents' to control our experiments and conduct them is a safer place, but that doesn't stop the playing. Besides engineers don't like being wrong, so they do the proofs even if it is just for themselves.

Back to the blog post link, which was another one I received from Cary. It's a good, thought provoking post, and it mentions some of the shortcomings I see in the application of Agile methodologies. If you take a look at the section in which the author, Jason Cohen, describes the 'general line of reasoning' behind Agile, pay attention to his list of 'therefores'. I see a few that I don't think should be managed via Agile. For example, do you really want to build your architecture iteratively, based on customer feedback? By the time the customer is giving you feedback on an inadequate architecture, you've already got serious problems. That's just one example, but maybe if we stop using Agile as a general purpose tool and start using it where it is most appropriate, i.e. the application function and interface, we'd get all the positive benefits from Agile without the drawbacks.

user centered design

It's the day before the new year and I have two topics related to development that I am hoping to complete today to wrap up 2009. Then I plan to refocus this blog on its originally intended topic - measurement. I can't promise not to wander off topic again but I will do my best.

A few weeks ago, Cary Millsap sent me a link to The Fable of the User-Centered Designer. It's short and an enjoyable read, so I suggest you download a copy and read it before continuing. For those who don't follow my advice, here are the three secrets of user centered design:

1. Early and continual focus on users and their tasks

Spend time with the users to gain an understanding of their environment, how they work and which tasks are critical to their job function.

2. Empirical measurement of user behavior

Don't ask a user what they think of the design, watch them use it and measure the usability of the design. Measure how efficiently they are able to complete tasks with your tool.

3. Iterative design

Good design must be an iterative process which will result in many, many possible designs, each of which needs to be tested and retested for usability. Use prototypes (mock-ups in my lingo) to measure usability before beginning to code. In the fable, they begin with paper prototypes and move to electronic prototypes. Your design should be stable before you begin the serious code work.

The fable makes some excellent points about design, and how design teams get it wrong by focusing on just the visual appeal or just the technology, losing site of the real goal which should be a product that makes it easy for someone to do their job. IT tends to assume we know who the users are and how they will use the tool, but that can be a huge mistake. We also forget that other people are not like us. They may love the business function they perform with the software but they don't want to spend unnecessary time dealing with the tool or figuring out how to make it work.

To put it in perspective, I'm a database geek. I like data and columns of numbers. I like figuring out how Oracle solves an optimization puzzle or how the OS or hardware should be configured. I like experimenting with different approaches as I work. Ask me to do those same things with my desktop solution and you'll piss me off. I hate having to deal with desktop software and updates - that's why I use a MacBook. I hate waiting for graphics to load or making a document look pretty - I'd rather work on a Linux box and use vi. Just because I'm interested in one aspect of technology that doesn't mean I'm interested in all of them. More importantly, just because I'm interested in the database and the guts of the data that doesn't mean my users are. They just want their data returned accurately and quickly. Everything else should be transparent to them.

Reading this fable reminded me of a few events in my job history. I started my career in industrial engineering and manufacturing, but from the beginning, I tended to get all of the system related responsibilities, mostly because no one else wanted them. Over time, I became the translator between IT and manufacturing and those dialogs were very much like watching a gathering of the United Nations. A meeting would include representatives from various manufacturing teams, IT project leads and designers, and me. The manager from the electrical development team would describe a task that his guys needed to do, and the IT people would look at me and I'd explain it in their terms. Then they would describe their solution, and I'd translate for the electrical guy. It was literally as if they spoke different languages. We didn't start out doing it this way, but after several projects failed to provide what was expected, management altered the format. The UN-like meetings took longer than the old style specification meetings, but in the end, the development cycle was faster as there was less rework. Plus, everyone's blood pressure was much improved and when you work with older manufacturing guys, that's important. (There were more than a few heart attacks on the premises during my years at Lockheed.) The communication gap is probably not as wide in all business functions but if you take the time to watch how your users actually work, you might find that what they actually mean is not always what you thought they meant.

I've implemented and supported both PeopleSoft and SAP systems at different companies, and the differences in user adoption of those products illustrates user centered design perfectly. My experience is with the Human Resources and Student Administration modules of PeopleSoft, and the functional users adored PeopleSoft. While there was usually some resistance to change in the initial implementation, once they started using the tool for part of their work, they wanted to do all of their work in PeopleSoft. I don't know how PeopleSoft did their usability studies, but they did something right. PeopleSoft seems understand how the HR user works, although I still find most HR people baffling - they are the antithesis of the manufacturing types I was used to.

With SAP, my experience has been the exact opposite. Users hated to interact with SAP and would go out of their way to avoid it. They would hide some aspects of their job functions out of fear that someone would decide it needed to be coded into SAP. While there may have been an occasional request to add a module, it never came from the end user. It came from a manager or a different team that needed to be able to connect another data point.

The PeopleSoft screens were 'friendlier', but I don't think that's the primary difference in user adoption. When you build a tool that makes is easier for people to get their work done, they will use it every chance they get. Yes, there are all sorts of theories about resistance to change and users being unwilling to learn new methods, but the reality is users will change if the tool helps them work better. If users are not integrating a new tool into their tasks, then the tool sucks. It's really very simple.

Perhaps the most significant point that the fable makes is that users can't always tell you want they need because they don't know what is possible. If they've been making do with spreadsheets, how can they comprehend what is possible once their data is in a relational database connected to other related data sources with a usable front-end application? The fable references the famous quote from Henry Ford: "If I had asked my customers what they wanted, they would have asked for a faster horse." How many other products have been developed in the last 100 years that we can't live without but never comprehended could have been built?

Now for the 'constructive criticism' portion of our program. Like many of the new development theories and methods, the fable talks exclusively about the design of the user interface. There is no mention of designing for data usability or making sure the architecture is scalable. However, if the data source is not usable, the iterative process will be extremely painful. And by the time you get to the electronic prototypes, you'd better have some real data in there or your usability studies will be flawed. Once users can see what can be done with the data, that's when they can start giving you valuable feedback on what they need and that's when they will change the design on you. Remember, users can't always tell you what they need because they don't know what is possible until there is something tangible in front of them. But if the data has been structured into a solid 3rd normal design, the presentation of that data will be adaptable to their changing needs.

I'm starting to believe that it is safer to assume that every new development method should be considered a completely separate process from the database design. Seems like a user centered designer would recognize that the data structure needs to be usable so the information can be assembled and reassembled as the user needs to see it. A user centered designer would know that it's important to have the right architecture, so the tool performs quickly and efficiently. After all, if it's important to measure the amount of time it takes for a user to complete a process, it's also important that the user doesn't have to wait for the screens to populate. (although that's not something you'll see with the paper prototypes) I do know that a slow system will not have users flocking to use it, so a non-scalable system will have a low rate of user adoption.

The 'Agile' word is also referenced at one point in the fable, but I've come to the conclusion that anyone who uses that word needs to include a definition. Everyone seems to do Agile differently: it's amazing how many different versions there are just within my current department, much less in the entire development world. It's like the word 'music'. The music I listen to may be very different than the music you listen to and assuming we both like the same music would be as silly as assuming we both use Agile the same way or that we know what the user needs based on words. We need to watch and understand the user's actions if we want to be effective in software design and development.

Ok, that's one down but it's already 2:30. I'm still aiming to get that second post up but I've got a few other things to do first.