Moved - new blog site

Finally got the new site up and running on google app engine...update your link to http://www.homesteaddeveloper.com (and http://www.homesteaddeveloper.com/rss for the feed).

Bill.

The Wow! Factor

We all know the saying that states perception is 9/10 of reality? End users perceive the level of quality in software based on how they like the user interface and the experience it provides.

If end users perceive software to be of good quality (based on their individual user experience) they will be more forgiving and understanding when problems inevitably occur. On the other hand, if end users don’t enjoy the user experience and perceive that the software is of poor quality they will be much more demanding and unforgiving when problems occur.

It’s hard to exceed expectations on a software development project without delivering a great user experience. We cannot deliver a great user experience without focusing on interaction design, ease of use and consistency in the user interface. We need to inject ‘Wow!’ into the user interface.

What is the ‘Wow! factor’? It’s when your target end users start to use the UI and immediately get excited about how it well streamline their work, or make their jobs easier or more enjoyable.

How do we get to ‘Wow!’? Some thoughts:

• Establish UI design guidelines early on in your project. Make sure the UI implementation consistently reflects the UI design guidelines. Continue to enhance and refine the UI design guidelines based on implementation feedback and end user feedback
• When designing and building the user interface make sure to continuously try to adopt the end user perspective to critique the design and implementation. We can understand our end users by using activity modeling to become familiar with their documented activities and role profiles. This includes the activities, performance characteristics and design implications documented for each role
• Understand standard usability heuristics and apply them to the design and implementation of the user interface.

It’s often implicit or overlooked, but injecting the ‘Wow!’ factor into your projects goes a long way towards exceeding end user expectations.

Calling the shot

Time to start blogging again....and how about a sports analogy? On October 1st, 1932, at Wrigley Field in Chicago Babe Ruth hit what would be his last World Series home run as the New York Yankees beat the Chicago Cubs 7-5, on their way to a four game sweep of the series. What made the hit remarkable was that Ruth allegedly pointed to the center field bleachers before dispatching the ball there. A famous sportswriter immediately wrote that Ruth had actually pointed to where the ball would land before taking his fateful swing...and a sports legend was born.

The fact that Babe Ruth was probably pointing at the Cubs dugout in response to being jeered has been lost in time, because our nature wants us to believe in the hero rising above normal performance to perform incredible acts.

Project management for software development sometimes feels this way - when as the leader of a project you are expected to say exactly how things will turn out. Since we're not all Babe Ruth about to hit a last legendary World Series home run, we have to rely on other methods.

More often than not we are required to specify some end result and a time line before the project starts. We are asked, in a sense, to 'call the shot' before the team even picks up a bat. So, having called the shot, what fundamental things are involved in trying to make it happen? Thought I'd share some thoughts, if not gross simplifications (apologies to my PMI friends in advance), regarding where you should focus to help make your 'called shot' become reality:

• Resources: Team members (skills, experience, availability, attitude), facilities (desks, computers, networks, etc), and tools (source code, automated builds, code coverage, etc). Avoid deficiencies in any of these areas.
  
• Requirements: Stories, broken down into tasks, solid estimating (relative for stories, detailed for iteration tasks), lightweight task & progress tracking, user buy-in to author the stories and their accompanying tests (i.e. how do we know if feature x is complete?)
  
• Design: Do we have a clear technical design? Interaction design? Does it match the skills & capabilities of the team? Is it balanced to handle complex and simple functionality? Are the abstractions reasonably waterproof? Is it pragmatic and as simple as possible?
  
• Organizational support: Are we communicating clearly and frequently enough to all stakeholders? Are risks well understood and mitigated? Are we clear on our expectations of all stakeholders? Do the right people care about our project?
  

If you pay enough attention to these four basic areas, with no 'fuzziness' in them then you'll have a much better chance of actually calling your shot. Whereas some still question the Babe's heroics, you'll at least have the satisfaction of having your called shot well chronicled.

Nobody ever got fired for buying...Microsoft??

Like Yogi Berra said, sometimes “it's like deja vu all over again”.

I guess I’ve been at this long enough to remember back to the 1980's when, in corporate IT, we tended to look for the IBM solution first, regardless of what other options there might be, and often overlooked the fact that the IBM option really sucked, as long as it had the illusion of being consistent with our other IBM software.

It seems to me that Microsoft has now assumed this role in corporate IT, with their products being the “safe” choice (remember the old expression “nobody ever got fired for buying IBM”?). The hard part for myself is grappling with the default=Microsoft mentality. It seems increasingly common to make uninformed platform and product decisions that default to the “safe” choice.

Don’t get me wrong, I truly believe that Microsoft is capable of producing innovative software when they are pushed. Things like C# 2.0 and the XBox 360 are examples of products that Microsoft is capable of producing when the chips are down and they are behind the competition, and I'm a big fan of those innovative products. Microsoft earned their current position in IT by coming from behind and delivering more value than the competition – they just don't have a great track record of innovation once they are in front.

It's just that a lot of people in IT are falling into the same trap as the IBM fans back in the day - “If it's good enough for Microsoft to release it must be good enough for us.”.

A lot of organizations are driving their businesses forward using alternative platforms. I listened to a Paul Graham talk a while back about open source and blogging. He's quite prolific with one-liners but my favorite one was "At this point, anyone proposing to run Windows on servers should be prepared to explain what they know about servers that Google, Yahoo, and Amazon don't".

What should we be doing? Challenge assumptions and herd thinking, focus on best of breed, identify where the value in a product comes from and use that to drive our selections. It's OK to use Microsoft products - heck, practically everyone has to – just make sure you're not using it just “because it came from Microsoft”. There are a lot of smart, pragmatic people at Microsoft – look beyond the product marketing and get them to help you figure out if a given solution delivers the value you need.

Hiring skills

In the IT world we often run into gross oversimplifications. One of my favorites crops up during the hiring process. We sometimes see the requirement for a software developer simplified down to ‘we need a .NET developer’ or ‘we need a TIBCO developer’. There’s an implicit defocusing on skills other than the specific technology mentioned.

Hiring the right people is one of the most critical activities that an organization needs to get right so why the oversimplification? Part of the problem is that it can be difficult for HR professionals to assess technical skills so using generic terms makes it easier for them to screen candidates at a very coarse level. The problem is mitigated if the next step in the process involves a thorough assessment of the candidates skills – not just checking off the 'technology X' box on the interview sheet!

So what skills should we be looking for in software developers? Leaving aside non-technical skills (like communication and leadership) for now, I would focus on 3 areas:

• Languages & tools.Here’s where we’ve traditionally focused in IT interviews.What programming languages, tools and frameworks is the candidate familiar with?Look for breadth and depth.
• Design.What kind of design track record does the candidate have?How have they designed systems or components in the past?Do they have a solid approach to software design?Typically depends on experience, but is a good indicator of capabilities.
• Methods & practices.What software development practices has the candidate used in the past?Practices range from code authoring (e.g. code reviews, refactoring), to code collaboration (e.g. source code management, continuous integration) to organizational (e.g test driven development, iterative development).Look for ways the candidate has tried to improve their development process.

Use a simple range (developmental, experienced, expert) to rate the candidates ability in each identified skill. Of course, beyond skills there are other important factors such as attitude and aptitude, but these tend to be more subjective.

So next time you’re asked to hire a ‘technology X’ developer, think about how you assess their skill set.

Podcasts - IT radio to go

I've had a lot of electronic 'devices' over years. Some of them I used for quite a while and got decent benefits from while others I felt never really paid back the investment. The device that changed all this for me was the iPod. I picked up a 30GB iPod photo in April 2005 and since then it's become an essential part of my day.

The obvious use for my iPod was to load up my music collection (long since converted to MP3 format) and my digital photo's, but one thing I was excited to try was podcasts. Podcasts are the fusion of portable mp3 players, PC recording technology and RSS news feeds. April 2005 was early days for podcasts but since then the number of available podcasts and their maturity has increased exponentially. Now I'm hooked on this form of grass-roots broadcasting (or DIY Radio as Doc Searls put it).

I listen to a number of podcasts every week based on topics such as science, environment, current affairs and video games, but one of the most interesting subjects available in podcasting is IT.

Think of listening to IT podcasts as attending virtual conferences on your own schedule, where you get to choose which topics and speakers you are going to listen to. My favourite IT related podcasts are:

• IT Conversations. The 'granddaddy' of IT podcasts, produces more shows by far from many speakers than any other podcast. Also produces a lot of podcasts based on talks given at popular technology conferences.
• Software Engineering Radio. A couple of interesting German guys talking about hard-core software development issues.
• .NET Rocks. Microsoft-backed podcast discussing various aspects of .NET software development. Some interesting topics and speakers (just watch out for the Rocky Lhotka smackdown!).
• The Java Posse. By far and away my favourite IT podcast. Produced by a group of four friends who have been in the Java space for many years working at companies such as Borland, Sun, Apple and Google. They talk about the key issues in Java software development with a humility and sense of humour that makes for great listening.
• FLOSS Weekly. Hosted by Chris DiBona & Leo Laporte. A series of interviews with leaders from the open source community.
  

So, if you haven't already, it might be time to make IT podcasts part of your professional journey. Already there? Let me know which IT podcasts you like.

Developer TLC

Software development projects fail for many reasons. Issues with budget, direction, management, customer buy-in, scope, etc. can all result in failure.

Another common problem is the failure of the development team to deliver the right functionality on time and on budget. What’s the best way to tackle this fundamental issue? Hire good developers and create a working environment that allows and encourages them to excel.

How does a leader create this environment? Here’s what I think:

• Understand and embrace good software development practices. There are common practices that reinforce a strong focus on software development activity in the project, regardless of the technology or application being developed. Understand things like unit testing, refactoring, code reviews and continuous integration and make sure they are planned for and supported in the project.
• Put the focus of your projects on delivering working software sooner (as opposed to heavy process or big design up front methods). Release early & often, get lots of user collaboration & feedback, use short cycles. Let the developer work ‘see the light of day’ as early as possible – the team needs the feedback.
• Make sure your developers have the best hardware and software you can reasonably arrange. Things like dual displays, laptop RAM and software tools go a long way to support developer productivity.
• Invest in developer technical & industry training in the form of a professional development program. Give your developers a budget and time allocated to their personal skills development. Put support in place to help them plan/schedule these activities and maximize the benefit. Let them buy any book they need.

Hire good developers, treat them well, and you’ll be halfway to a successful project no matter what other issues you may be facing.