Process evolution

With every new release of an upgrade/update comes a new opportunity to re-examine the processes that lead to it’s development. As the software developer I can only refined the automatic processes that lie between the human interactions. I cannot click the button that starts the next step, I can only perform what comes after the button click – up to when another button needs to be clicked.

When the new release is made, a business should also be thinking about whether or not that button needs to be clicked in the same way, or for the same reasons.

This way the business processes are advancing effectively.

Express yourself

I’ve just spent two hours talking with my developer about his understanding of The System for a new project. It was an excellent learning experience. I was given a lesson in technical writing for someone else. Where I thought I was being detailed, I was confusing the issues.

Now I have a better understanding of what is a good descriptive method for him. With this information I’ll be updating the existing requirements document, for my internal use. It’s an iterative process that will never end, but well worth the trip.

What’s programming like?

I came across this http://www.independentdeveloper.com/archive/2009/03/17/programming-is-like-a-dream” target=”_blank”>Independant Programmer article (via http://weblogs.sqlteam.com/jeffs/Default.aspx” target=”_self”>Jeff’s SQL Server Blog) which tries to explain what it is like In The Zone for a programmer.

It even neatly describes an interrupt routine (boom boom) for non-programmer types, like your boss, to use when they need to get in the way. Possibly worth forwarding on to the higher ups who are prepared to take on a little personal development (or HR management).

Gooey G.U.I.

I found an interesting concept for “The Next User Interface”, over at http://www.techcrunch.com/2009/10/13/10gui-one-very-slick-desktop-multi-touch-concept-video/” target=”_blank”>TechCrunch, called http://10gui.com/video/” target=”_blank”>CON10UUM.

What I like about it is that from start to finish, they have sculpted a new method of interaction with our machines. It’s a pity that we are so attached to our keyboards, but for the moment doing without them is probably too big of a change for anyone to take too seriously. While we continue to depend on the written word for most of our computer based business interactions we can’t do away with them yet, although voice recognition is the next logical replacement it’s not quite there yet (apparantly).

CON10UUM is certainly food for thought and there are products out there that already perform similar tasks (http://www.apple.com/macbookpro/features.html#trackpad” target=”_blank”>Mac touchpads, http://www.wacom.com/bamboo/bamboo_touch.php” target=”_blank”>Wacom Bamboo Touch) but they really only add a thin set of commands to the existing U.I.s that we already use.

Involve the client

I was talking to one of my developers a few days ago, about how I like to demonstrate completion of The Design Phase.

Having a face to face discussion about the project’s design is a good way to start, but having an interactive presentation (model) to help them “feel” their product is orders of magnitude better. When it’s interactive the client is engaged with the product early and is able to experience their product prior to development. This way I can quickly and simply prove that I was listening when they were telling me what they wanted (during the Requirements Phase).

And with a model of version (n) in front of them, the client can begin to think clearly about version (n+1).

Because everyone in this industry knows; A requirements document is never a perfect description of what the client wants, it’s the best version this time around.

Business Cards

I was sent an invitation to trial a new product about a week ago: miniture plastic business cards and I thought I would just quickly share my excitement about it.

In terms of a user interface, the website was beautiful. So simple. So elegant. Such a great User Experience. Have a look yourself – http://www.squizcards.com” target=”_blank”>www.squizcards.com

The cards are actually really great too, but that’s bye-the-bye for me. What got me in and kept me fascinated, was the ability to quickly customise someone elses designs and make it my own. Hats off to the designers, excellent work!

Documenting for Outsourced Development

I love the idea of outsourcing development. It forces you to evolve your business processes and it’s entirely in line with the code re-use paradigm found in programming:

[Try to] write re-useable code.

When you are outsourcing your development (especially when you go off-shore) this becomes:

[Try to] write re-useable documentation.

You can no longer have a casual conversation at the coffee machine* with Fred the Coder about what it was you actually meant when you said, “The system needs to save the booking”. The document must stand by itself, it needs to be portable, it needs to be re-usable.

The document creator has to provide a Rosetta Stone for the project: A record of the non-technical description provided by the client and a cohesive translation into the technical description for the development team. When questions are asked by either group, those answers should be noted and incorporated into the (next) version of the document. Even after sigining off on a final version.

If you can provide the perfect Rosetta Stone, then you will only have minimal interaction with the development team which reduces the management overheads. Badly written documentation results in far too much live translation and that leads to missed dead-lines and budget blow-outs.

*or PS3 or Kitchenette etc.

Expectations, I’ve had a few…

I’m am getting a little involved with http://www.joyent.com/joyeurblog/2009/09/05/is-the-customer-always-right-no/” target=”_blank”>this article at Joyent about sticking up for your team, even if that means saying no to a customer. It’s a topic close to my heart, especially as I start up a new project.

The crux of the problem is that a client who doesn’t understand what they are paying for needs to be educated; and that education actually costs the provider money, one way or another. If the cost of educating that client is more than that client is worth to the business when do you cut your losses?

Do you hope to have 99 easy clients for each hard one and have the many pay for the few (the typical approach) or do you show the hard one the door? What if the ratio was 999:1? 9999:1?

What’s the break even level? Is it worth it?

I don’t think there is a simple solution, each situation has to be evaluated individually. Before you go in the room, you need to know what you are willing to spend on educating the client. What proportion of the project is going to be invested in managing the client’s expectations. Who’s going to do it? How will it be done?

Joyent has massive archives of forum posts that deal with almost all the crazy things that can happen in their hosting services, they even have a wiki. Is it enough? For me, Yes. For others?

Even 499:1 is probably worth it…

Natural Development

In 1859, http://en.wikipedia.org/wiki/Charles_Darwin” target=”_blank”>Charles Darwin set out his theory of evolution by natural selection as an explanation for adaptation and speciation. He defined natural selection as the “principle by which each slight variation [of a trait], if useful, is preserved”.

My take on natural selection in software is that with each subsequent update, the functions that are most useful should be preserved and those that aren’t should either be dropped, or improved if they show promise. This method will quickly produce effective systems that are tailored for their specific requirements. With each successive update, the system becomes more aligned with it’s intended use, even if that changes from time to time.

To achieve this result there needs to be a few things first.

• Regular updates of the software
• Measurable feedback on the changes
• Clear objectives of what you want to achieve

These roughly translate into offspring, fitness and drive; Each generation (update) of the system needs to be evaluated (feedback) for fitness against the objectives (drive).

Software development has already formalised this process (in 2001), calling it Agile Software Development. The fundamentals are http://www.agilemanifesto.org/” target=”_blank”>here and I’ve been doing it for a long time.

Scoping meeting

After several years of “pie in the sky” conversations and two months of pre-development work I have finally been able to hold the first Scope Meeting for the development of a client’s customer self-serve website. It’s been a long time coming, but now we can start building the crowning glory to their business’ IT systems.

The first session is very important because it allows me to find out how big they want the final product. From there the process of winding back the scope for the first version can begin. Sure, the client can have everything they want, but the pathway to getting it needs to be clearly defined and well maintained right from the start.

While the answer to “Can we do that?” is almost always “Yes!”, the most important part of the reply is “Which version would you like that to be available in?”. The trick to getting it done (and paid for) is to manage the clients expectations. If they want something NOW that’s fine, what is the client willing to delay so it can happen?. If they are willing to make that trade, great, let’s do that. If not, well, sorry, that’s not possible under the current conditions.

I don’t have to hide anything. I’m educating the client so that eventually they start asking these questions before I do. Suddenly the hard part of dealing with the client evaporates.