Andy's Mind

Tempted by a recent promotional offer I upgraded to Windows 8 three days ago. So far my experience is mixed, but I’m not going to bore you with that. Instead I want to point out two things that Microsoft is doing with Windows 8 that are in my opinion noteworthy.

First, this is the first true innovation in computer UI in years. Last thing this innovative was iPhone’s UI. While Android is – in terms of its UI – merely a clone of iOS Windows 8’s tiles are something new and very different. It remains to be seen whether this UI will be accepted, especially by the desktop/laptop users. By necessity innovative UI has some learning curve that is much steeper between Windows 7 and 8 than it was between XP and Vista/7. But even if people will reject it and MS will have to revert to the “Start” menu (invented for Windows 95 almost twenty years ago) they should still be praised for at least trying something totally new. Brave, risky – and, I’d say, a bit unexpected coming from an aging corporation.

Also, the concept of unifying the UI across devices to deliver a coherent experience on all of them is interesting. It is not exactly new – last time Microsoft tried it the other way round: Windows CE had desktop’s UI that required a stylus to navigate. In Windows 8 the desktop did get the Start screen that was clearly designed for touchscreen devices. While it usefulness on a laptop/desktop is dubious I have to say it is surprisingly easy to work with using keyboard and mouse.

But this concept serves another purpose. I think I see the MS’s strategy behind it. They want to regain lost position in the mobile world by leveraging their dominance on the desktop. They hope people will like Windows 8 on laptops and tablets enough to buy Windows phones to go along with it. This is both clever, daring and something they successfully did before – when they overslept the Internet phenomenon they fought they way back by winning the browser wars from their Windows stronghold. Now they want to do it again and the time is high, because if things continue as they are few years from now keyboard-equipped computers may be used only by professional software developers and the like. So current desktop dominance will become less relevant and it makes perfect sense to us it now while it still matters.

All of that of course explains why they sell Windows 8 for around $50 – much cheaper than before. They will do everything in their power to make sure everyone will be familiar with the tiles interface. One company that certainly hopes this will work is Nokia – but this is a completely different story.

When I talk to software developers^[1] I always stress that as professionals they have an ethical obligation to deliver good code quality. I’m not alone in this – people far more known and respected, like Ken Schwaber for example, keep on saying the very same thing for years now: if you are software professionals you have to act like professionals.

This obligation is very much linked to the so-called structural quality (how well the code is built), because this aspect of software has a great effect on our clients and future users of the software we produce, yet it is completely hidden from the clients. Clients can, for the most part, detect visible functional defects (application no doing what was intended, system ill-behaving etc.), but they are usually not equipped to assess how well the software they pay for has been built internally. However, in the long run it is the structural quality that has a higher impact on the total cost of ownership and other financial parameters of a software project. The customers are obviously not professionals in the field of software development, but they trust that developers they hire are. Therefore, clients have all the right to expect good quality (understood as well built, testable, extendable, maintainable code) even if it was not explicitly requested in the contract. However, for now software developers yield to pressure and produce horrendous code just to meet time constraints (commonly known as “deadlines”).

A good parallel is civil engineering. If we hire a construction company to build a building for us we expect it to be structurally safe, built from safe materials and adhering to widely accepted engineering standards. Clients are not expected to be civil engineers or construction foremans capable of personally ensuring it is the case – clients trust builders will do their job properly and by virtue of clients’ trust it is the builders’ ethical obligation. This ethical obligation is so widely recognized in societies, that is has became a legal obligation almost everywhere in the world.

It is only logical then that the same will happen to the software development profession at some point. What I wait for now is a lawsuit that will claim damages from a software development company for poor structural quality of a working software product “delivered on time and within scope”. A client will finally come to claim damages after they find out two years after delivery that while the product works its code is unreadable, it doesn’t have an automatic test harness (unit testes, automated acceptance tests etc.) and it is therefore very costly or impossible to extend it further. I am not a lawyer, but I do think it would be a winnable case.

I wonder if those in the software development profession really need such a wake-up call from the legal system before they will understand that it has their obligation to do things right – not just “on time, within scope”.

[1] By “developers” I understand everyone involved in building a software product – not only programmers, but also test engineers, DB gurus, usability designers etc. etc.

A question I frequently see asked on the Internet is whether agile teams should release every iteration (or even more frequently) or not. When asked in relation to Scrum the question is usually if software should be released every sprint. With other methods – like now-popular Kanban – the question is what release frequency would be right, as the method itself doesn’t say anything about it.

I think that many times this question reveals an underlying confusion between keeping software releasable and actually releasing it to the public. I think one construct from Scrum can help clarify things here.

Scrum calls explicitly for a “shippable product increment” to be delivered at the end of each sprint. It means that the end of each&every sprint a new version of the software must be ready that passes the quality criteria (in Scrum expressed as the “definition of done“) and ideally includes all the features the team committed to delivering at the sprint’s outset. However, this new version is called “shippable” not “shipped” for a reason. This reason is that whether to release a new version of software to the users is ultimately a business decision.

This distinction is very important. Just like the shape of the backlog is a result of a whole series of business decisions made by the Product Owner the decision to go with the product to the public is a decision that can be (and quite frequently is) made by stakeholders. As such it is definitely out of the scope of any process/method managing the development itself or the team doing the development.

There are of course numerous benefits from actually releasing each and every “shippable product increment“: greater user satisfaction, faster user feedback, better discipline in the team and less risk (deploying smaller changes is less risky than deploying a big-bang, all-changing release). In fact this is what we have been always practicing, also when working on our Scrum tool.

However it has to be understood that situations (companies, products, etc.) vary and can be very different. Sometimes there are other factors involved – for example domain (in embedded software releasing every sprint may not be even possible), market influence (eg. developing a major feature and not wanting to let on before it is complete) or alignment with other elements (like when software is part of a larger project, where other things have to be in place for the new features to be used or usable).

So, a team can be agile even if what they develop is not released every iteration. They just have to work as if it was in terms of quality and effort spent testing the software to ensure that it could be deployed when needed.

We have released a new version of our on-line hosted Scrum tool last week – the Banana Scrum. The most important addition is, of course, the automatic registration form, but we also improved the way in which the user interface works. We start to get ideas from our users, who generally like the tool but will undoubtedly help us make it better.

Which is good, since I think there is a definite need for a simple, on-line tool to assist agile teams in their work. Which leads me to another topic – resistance to any such tools. When someone asked about a tool for Scrum on the Yahoo Scrum group there was a bunch of answers advising not to use any tools – use a wall with velcro attached index cards or, at the very least, Excel.

Agile community in general and Scrum community in particular seems to be very attached to “good old” physical artifacts, like index cards, hand-drawn burndowns, hand sorted backlogs etc. I can respect that but I’m a completely different person – I’m a “paperless guy”.

The only thing I still prefer on paper is books. Hand drawn brundowns can be nice if everyone sits in the same room from 9 to 5, but we have a much more relaxed atmosphere – everyone has to be in for the Daily Scrum but otherwise people can work from where they want when they want. Whiteboard is great for sketching things or making notes during a meeting but I don’t think it is good to make it a permanent repository for anything. I think if we work with computers and systems and web apps we should use them. How credible we are telling other people our applications can save their business if we stick to index cards and velcro?

So, I don’t like it when some agile gurus look down us, paperless guys, when we confess we use software tools to manage our projects rather than walls, cards and boards. I don’t think it is a good idea to be too dogmatic about tools, I agree with that, but it also applies to the old paraphernalia of the paper age.