Dogfood, Product Design and Microsoft

Looks like there is a bit of a distributed thread starting up around the dogfooding of VSTS at Microsoft and the impact that has on design decisions that go into the product. The root of the thread is this eWeek news article by Peter Coffee.

Rob Caron hit the nail on the head when he said TFS is a flexible platform when it comes to supporting processes but I would like to take time to point out (as Peter Coffee did) that Microsoft produces an extraordinary amount of software, and given the level of production it is at a very high quality (compared to what I’ve seen some people who spout the opposite produce).

I remember on many occasions wanting to understand the Microsoft software engineering process better and in many cases I wanted to scale down and emulate it in teams that I have worked with. If we look at the history of the development of Windows from a source management/development point of view you can see just how many hard lessons they have learned both in terms of the requirements they have for their tools and also the processes they need to ensure they ship quality products.

It is important for Microsoft to embed their requirements into their own products to give them that industrial strength edge (just look at the scalability reports) but also scale down to your average development teams size, which I have seen TFS do first hand.

Developer + SOE = Living Hell

Graham Gardner is writing about building standard operating environments (SOE) and his first post outlines a simple process of how to get from nothing to your first candidate SOE. As a developer I have always treated the SOE process with a degree of suspicion because more often than not its like a pair of handcuffs. So while this post is not a retort to Graham, its a plea for understanding from software developers to system administrators everywhere!

If you are a developer who has been responsible for getting a development project off the ground in a corporate environment you will be familiar with the incredulous looks you get when you tell system administrators that you what the ability to log into your machine as an administrator (note, I am being very careful not to start a debate here about whether your standard user account should have administrative rights or not).

It seems thats that no amount of explaining can convince some people that you can’t develop software effectively without having the ability to run as an administrator to debug processes and simulate multiple users accessing a system. Life can get even harder when the SOE is so locked down that you can download your favorite tools and install them (Reflector, NAnt, NDoc, and MbUnit) because you can change files in the Program Files directory.

Some organisations seem to alternate between having an isolated developer network and shoe horning developer requirements into the existing SOE. The problem of course is that developers develop software for a diverse set of deployment scenarios including web applications, windows services, desktop applications, mobile devices and various server products like SharePoint.

It gets interesting when you start talking about developing and debugging for the 64–bit platforms, most SOEs are going to get shot to pieces then. Basically what I am saying is that if you have a team of developers, get them two machines (it will cost less than the lost productivity). Give them a standard SOE machine and then give them another box and the flexibility to change its configuration to suit their requirements.

And for the record – no, you cannot all debug the one shared instance of IIS!

Daniel on Voice UI

Daniel has posted up a facinating entry about the viability of voice being the next generation UI and some of his experience to day with voice-enabled user interfaces. One of the really important things that Daniel touched on and what I would love to see him expand upon is the topic of emotion in user interface design.

In Daniel’s case we was made to feel self conscious about talking into the phone at a computer. Interestingly enough, thats completely illogical because people arround you have no idea you are talking to a computer, so unless you try to talk back to it like a robot there won’t be a problem.

Thats the thing about “User Emotion Design” (I just made that up – do you like it), its not always logical and in different scenarios a voice interface might make perfect sense.

One good example of where a user interface voice would make sense in elevators at large department stores and office blocks.

When I was younger my Grandmother took me to Myer in Brisbane and in the elevators in that building they had lift operators that sat on a stool in the corner and asked people where they wanted to go. Naturally, this was before they had algorithms to determine optimal routes to floors and optimal rest positions based on the time of day.

One of the neat features of this “user interface” was that you could ask it questions. For example you could say, I want to go to the floor that sells kids toys and the operator would wisk you up to the third floor.

Since then manual lift operators have all but disappeared (especially in office blocks where elevator space is precious at 8–9am in the morning) but the talking lift that tells you which floor you have currently stopped at the microscopic text next to floor buttons hasn’t really replicated the experience.

In this scenario voice could help quite a bit. In your average office block you could hop in the elevator and ask “I need to go to the Menzies meeting room”, at which point the elevator could go to the appropriate floor and provide instructions for getting from the lift to the room once you arrive at the correct floor. The vocabulary could be expanded to include any number of things such as where do you find a particular person, or where a good place to get lunch or a coffee is.

Once again we need to get over the emotional barrier, in this case of talking in the elevator which seems to be some kind of taboo in western society.