My first book: Smarter Software with Activity-Centered Design
This is a special moment. It is my pleasure to announce that I am about to become a book author. My first book is called Smarter Software with Activity-Centered Design.
There is so much bad software out there. But then there are people and companies that really understand how to make good really software and – in some cases hardware too. These people truly understand what it means to develop software. Hint: it is much more than writing the code.
Since the NATO conference on Software Engineering in 1968, which took place in Garmisch, Germany, numerous methodologies and processes for software development have been created. Most led people astray. Who knows why that is. But then it’s good to see that the good ideas are still around. That includes Test-Driven Development, which was envisioned at the NATO conference in 1968, and also the good ideas from Smalltalk, which is from the early 1970s.
Since then the topic of Human-Computer Interaction (HCI) has been research extensively and approaches such as User-Centered Design (UCD) came out of that. Although the focus on the user was a very good one what the user actually wants to do kept a bit in the background. Somehow a lot of UCD seems to be about how the user interacts with the shiny widgets on the screen. Many visual designers have contributed great looking interfaces but still too much software does not what the user wants from it.
A while back I stumbled upon Activity Theory and what has been called Activity-Centered Design since the mid 1990s. I started to research it and it made perfect sense to me to combine those ideas with Acceptance Test-Driven Development and other agile practices and techniques.
The book Smarter Software with Activity-Centered Design explains how to use Activity Theory to create software that makes sense to the user and really solves his problems. Yes, I know… That’s what everybody says. At least it’s the goal. We’ll see what the critics will say in a while.
Because short feedback loops are so important I have opted against my initial idea of finding a well-known publisher and am self-publishing. That allows me to update the book frequently and instead of having a small group of editors or only one, who may not be an expert on the subject, my editors is all of you my readers. The book will initially be available as PDF, ePub and MOBO (Computer and eBook readers) at LeanPub. Once the content has stabilized at bit better it will be made available at Amazon and eventually there will be a print edition.
As this is a software development book there is, of course, source code. For that I will use GitHub with public repositories. That also allows those who are interested in collaborating to fork the sample projects and send pull requests with their contributions. That’s going to be fun :-)
Further is there a dedicated website at http://activitycentereddesign.com and also a corresponding Google Groups, which is open to anyone interested.
I’m excited about all of this and I welcome you to check out the links I have provided.
When your organization is a software company
Innovation at the core of the business
Imagine you are the owner of a chain of restaurants with about 800 locations. One day during travel you discover a restaurant where they have little computers with touch screens on every table, which the patrons can use to order from the menu. You are so intrigued by that that you want to introduce this to your own chain of restaurants. Besides bringing food faster to the table you also envision benefits for your supply chain management.
“We are not a software company”
Your organization is a chain of restaurants. Everybody has a hospitality background and their only connection to software is that they use computers and several programs day in and day out to send email, write letters, do accounting, print checks for the patrons and run statistics. Most of these programs are quite easy to use but some require some training for up to a day. It’s probably safe to say that nobody knows how to actually make software but then some of your managers report how their sons and daughters are taught about computers and programming in school so it doesn’t seem to be so challenging. Sure, kids in school don’t work on large programs but the basics are certainly the same – isn’t it?
Reasons to keep it in-house
Because you view this new initiative as being so critical to the success of your business you decide that you should not contract an outside party for the development of it. You fear that this new thing may get into the hands of your competition too soon. Instead of awarding a contract to an established software development company you decide to hire a number of programmers and create the solution in-house.
Things to consider
Ideas are worth nothing. It’s the execution that counts. You can ask around at Venture Capital companies and they will tell you that they get hundreds of proposals and never would consider signing any form of non-disclosure agreement.
A company implementing software on behalf of their clients has no incentive to disclose one client’s idea to another client or to the public. Doing so would destroy their reputation and their company. There is nothing to gain for them. And don’t forget “ideas are worth nothing”. Even, if the contractor would disclose your idea to a competitor, it doesn’t really help the competitor. He still has to implement a lot of other things in his organization around the idea of the software solution to really take advantage of your idea.
Software development is a difficult undertaking. It is a risky and expensive business that requires a lot of experience and knowledge. Anyone can tinker with code and get something done. It is not difficult to learn how to write a script or even a Java program (or whatever other language one might choose). However, the development of a maintainable software solution that solves a business problem in the right way is a totally different thing.
By keeping software development of any dimension – if you write one line of code, you are basically already doing it – in-house, you have made the decision to learn how to develop software. As with any learning it will take time to master the subject. And while you learn a subject, you shouldn’t be delivering any critical work products created using the subject of your studies. Plus – and that’s more important in a business context – all that learning takes a lot of time. While you learn your competition may be working on the implementation of a similar idea and in the end succeed at executing their idea while you are still learning how to execute your own.
“We hire qualified software developers” I hear you say. Really? How can you know who is qualified? How can you judge someone’s skill without knowing much about their field? If you still want to keep development in-house, the best you can do is to hire a qualified advisor so that this person basically sets up your internal software development shop. But are you prepared to spend the money that such a venture requires. You are basically creating another company from scratch. And for how long? How will that new company – you may call it “department” – live?
I think that unless you are willing to transform your company into a software company you should find a qualified software development company and let these guys do their job. It is much easier to figure out who has successfully created software you like by looking at what they did for other clients than to build an organization from scratch.
Resisting change due to lack of trust
How I view someone has a dramatic effect on how we can work together. I will interact differently with people I respect or with those I think they are fools.
Those I respect I will probably approach in such a way that it shows how much I respect them. I may feel compelled to not approach them at all or at least not frequently. I may even be a bit afraid and worried when interacting with them. Not out of fear but because I don’t want to appear as a foul in front of them. Them respecting me might also be part of what I wish for and what I don’t want to loose.
With the fools it is much easier. I don’t really care about what they think of me and I don’t care who they are and what they do. They are just fools and not really of any concern to me. So when I have to approach them I do it as I could care less.
Besides the fools there is another category of people I might not respect. It’s those about whom I think they are working for me because they have to. Or even stronger: those who have to serve me. It doesn’t really matter why.
My own perception affects my interaction with those around me. In the context of work in larger organizations it is also the perception of my department or its leaders that affects how we can interact with the members of other departments.
I may view myself as being part of “the business” and define what a software system should do. Being part of or close to those who run the actual business puts me in some sort of position of power – simply because I define the work others are supposed to do. At least I may think of it that way.
Now in an act of human weakness I have found a large group of people essentially working for me: the programmers in the IT department. It’s “them” who have to deliver what “we” define. And speaking of business… They better do it on time and within the budget “we” have defined. Of course with high quality or else “we” won’t respect those programmers as professionals.
Change is a good thing – isn’t it?
No. Not really. By virtue of being part of “the business” I have earned myself a position of some influence and there is probably also some kind of job security for me. I am needed. I am translating and interfacing between the programmers and the other members of the business side in our organization.
Why would I want to change that? There is no incentive for me. Or is there?
Someone tells me that I should collaborate more with the programmers and testers. To help them create the right software. Why? I have already defined what “we” need and they should just build it as I have described. Their stuff usually doesn’t work the first time, which is probably due to sloppy testing and hence I blame the testers too. Because of that I have to waste a lot of time going and back forth anyway. I have my own reputation to defend and I can’t really babysit “them”.
New opportunities
On the other hand there might be new opportunities for me. If I can find a few of really smart programmers and testers I can trust, then maybe what seemed too risky for me and my career in this organization may turn into an opportunity. Sure, “they” still work for me but in a much closer way than before. I might try to sit with them and tell them examples of what the software should do. They have been telling me that they can use my examples as automated tests to verify their code. If that’s true, then I would really get what I have defined. That might boost my career in our organization. People may recognize my contributions. That doesn’t sound too bad. I should probably try it but first I need to find programmers and testers whom I can trust.
