Posts filed under ‘Business of Software’
Suppose you’ve got a new customer request for a feature, or maybe some great new idea by marketing people that will certainly increase sales of your product. Whether you are working in agile or a more traditional environment you are usually going to get a bunch of functional requirements (program should do a,b and c) and sometimes some non-functional requirements (performance targets, security). Sometimes you will also talk about usability – but in my experience you are never going to get “and it must look really really good” as a requirement. Most of my experience is in management systems development, so it is an assumption, but I am willing to guess that in most “business oriented” software eye candy is not a requirement.
I have recently read a great book called “Why Software Sucks?” and the basic idea of the author is that most of the people involved in making software come from very technology oriented engineering background (he uses the word geeks but lets not go there) and so to us everything is an engineering problem. We value technology and features and prefer more functionality over everything else really. So it is more natural for us to focus on features and performance and elegant solutions and mostly ignore usability and eye candy. But there is a catch – “You are not your user“. The things we value may be not the things our users value. And when developing applications we need to focus on what users want not what we think we would want if we were users. There are a lot of examples in the book of what happens when developers do what they think is usable instead of what their users would consider usable, and it’s not pretty.
But what about visuals and eye candy? Is it possible that the same thing happens here as well? Is it possible that while we as developers often consider eye candy irrelevant and even waste of resources, our users actually value it much more?
Well, some evidence is certainly out there. Take video games for example – good looking games with tons of eye candy just sell much much more. Take Hollywood – the big budget flicks with most effects often are criticized for being too shallow – and yet they are the ones that bring the most money and most people go to watch them. And how about Apple which took eye candy to a whole new levels? I have never used macs in my life, but if you ask me which is better mac or pc in terms usability – I would go with Mac.
So good looks sell but what is even more important here is that often good visuals are even more important than actual features. Macs have less software available for them then PCs. Big budget flicks have usually much less substance than independent movies. Most of recent blockbuster video games are just remakes of existing formula with almost no actual gameplay improvement.
So, yes, I believe that eye candy alone is worth a lot more than we usually think it is, even for applications that are not mass market oriented. (quick test, which bug tracking software is better: bugzilla or jira?). It’s great for first impression and thus sales and it’s great for continuing user satisfaction and thus retaining customers and creating word of the mouth hype. Features and usability alone are not enough anymore – your users demand that it also must look really really good.
It seems sometimes people just completely miss the point, even the brightest of them. Yesterday I was doing some prototyping for some new project I am working on which is based on JBoss EJB3 implementation, and since most of my background comes from Spring based project, I was looking for some answers. Nothing too complicated, mind you, I just needed some way to have one of the EJB beans to hold some shared state for all the application, something that is really straightforward in Spring, and something that I assume most of the applications out there today need at one point or another.
So, since I am no JBoss expert (yet :)) I did the sensible thing and tried to google it. Well, simple queries didn’t find anything for me (“jboss service”, “jboss singleton”, “jboss ejb singleton” etc), but in the end I stumbled upon something called @Service annotation which is a proprietary annotation of JBoss and can be used for this kind of stuff. Which is documented in this page. Which is while it is couple of pages long and have some code examples lacks one very basic thing – it doesn’t show how to use the thing in the simplest and most common use case, the one I was actually looking for. So instead of just copying and pasting the sample into my code and just running it and continuing to some other stuff I had to spend about an hour trying to figure this stuff out. (BTW the solution turned out extremely simple, elegant and it doesn’t require any of the stuff that is printed on that “help” page – I will put it in a separate post for others to reuse)
Which is why I think some people just don’t get it. I mean they are great developers and the eventual solution is really great and working flawlessly – but they miss the most important point. Open source frameworks and projects that provide infrastructure are just tools that allow us developers to solve some common problems. The reason these things are actually used (and not reimplemented in house) is that they provide solutions without the need to really go deep and understand all the implementation issues. When I write some application for an end user any time spent on figuring out some stuff that should have been in the manual is time not spent on providing value to my customer.
And this is my main point – you must know who your customer is. It just doesn’t work otherwise. And if you develop open source project that is going to be used by other developers – your customers are those other developers, usually the ones working on end user oriented software. This is not about who got the coolest implementation or the tightest algorithm or the most generic platform. This is about providing simple solutions to most common problems. And the reason why you should care is that even though we are not the ones paying your bills – your success and success of your project is directly proportional to its adoption rate. And guess where that adoption rate comes from.
Here is an example of project that does get it – Terracotta. It will take you less than 5 minutes to understand what it does and what problems it solves. And if you decide to try it out, it will take you less than 5 mintues to download and run an interactive sample of the technology (which is very cool by the way). Compare that site with site for JBoss Microcontainer which is the core of the new JBoss 5 release. I assume it is really good piece of technology but try to spend only 5 minutes on their site and try to understand what it does and whether is solves any of your problems. I couldn’t. And if I was really evaluating it I would just discard it at that point and go look at the next thing. Because there is always another thing (competition is great isn’t it?).
So here is my 5 minute rule – make sure your site and documentation can provide some initial idea of what problems you solve in less than 5 minutes. Make sure that for the most common problems the solution (including examples or better yet cookbook style recipe) is no father than 5 minutes away. Otherwise you are just not competitive with the projects (which by the way may be less technologically advanced) that do provide those answers. Take a look at the success of Spring Framework. Take a look at the success of Ruby on Rails when they took the world by storm using that video of creating a blog application in under 15 minutes. They did it despite the many technological problems that they had (like native threads and performance). This is really fast world. Help yourself by helping me quickly. Otherwise no one will care.
I am doing some thinking about what it takes to implement Scrum in an organization that is not used to or even familiar with agile concepts, let alone Scrum. When you start a new team or a new company implementing new methodology is rather easy – you select people based on what you believe the required roles and functions are, there is no legacy to overcome and everybody is open to whatever process you are installing. There is no inertia, there is no resistance and there is no conflicting interests you need to account for.
Of course the exact opposite is true when you are attempting to implement Scrum (or whatever else) in an organization with strong waterfall culture. It’s not just about telling people about how in Scrum you do so and so, go to this meetings, here is how product backlog should look like – and then you are done. It is much more challenging because of “that’s not how we are used to do things around here” – so not only you have to be able to teach what Scrum is, but also be able to overcome years of practise of doing something else.
And that is not the hardest part. It is impossible to make all the changes overnight – this stuff takes a long time to get absorbed and interned and used to. So there is going to be some time where organization is not going to be very “organized” for the lack of better word. And yet, there are customers and sales and support and contracts that need to be taken care of, and that cannot be “pushed back” until we can figure out how to do the Scrum stuff properly.
And this brings me to the concept of refactoring. In software engineering, refactoring is the art of taking an existing piece of software that maybe is using some old technology that is a bit obsolete by now, or maybe it is written in somewhat inefficient way and taking that piece of software and rewriting it in such a way that from the outside it keeps looking exactly the same, performs exactly the same function (but better) while inside it gets completely overhauled and made more efficient, with less bugs and easier to maintain. And I call it an art because yes there are some practices and tricks which help you do that refactoring, but in the end, every software is different and what might have worked on a previous project wouldn’t work on the next one, so to be able to do this and succeed requires some flexibility and creativity.
And I think similar art form should be developed for implementing Scrum in organizations that are currently stuck in the old ways. The similar challenges apply – keep the outside interface, support clients, make the sales, while in the same time transforming the entire organization to much more efficient, flexible and adaptive proceses. And yes, even though some techniques are probable shareable, in the end every organization is different and it will take each one a unique path on its road to agile success.