Technology is transient!

For a little over a year I’ve been planning to write a book on what makes a good software developer. This kind of book isn’t new, my personal book shelves is full of them, not to mention the hundreds of blogs and essayists sites which offer insight into what it takes to become one.

These books describe hundreds of different factors that will improve the developer lot, reams and reams have been devoted to:

  • Environmental factors,
  • Team structure,
  • Methodology,
  • Psychology.

The really good ones will make an impact and will change your life in an instant. However, the majority of developers I know consider these books pointless because the only books they think they need to read are the technical ones.

At work our book shelf is littered with titles such as WAP in 21 days and ASP in a nutshell. We’ve got more O’Reily and Wrox book then I’d care to mention and it was when I saw these literary carcasses getting dusty in favour of the latest technology release (“use dotNet to cook and egg “or something like that) that I decided enough is enough.

Transient Technology?

When I started programming I used Pascal, then Visual Basic, then ASP (VBScript, Jscript) and now (when I code) it’s in C#. Let’s not forget the forays into Delphi, Java, and C++. Plus my frequent use of TSQL, and other propriety languages such as MT’s templating system. However, rather then listing the skill portion of my CV I have a point I want to make, which is we very rarely stick with one programming language so why do we spend so much time learning the nuances of a programming language and not the supportive skills that enables us to adapt to the environment a developer works in?

I’m not suggesting that there isn’t a place for technical books. That would be absurd! My point is that in order to stand out from the crowd a developer should taking time to ask question and learn about best practice, fundamental principles, why and how developer tools work (I’m thinking Visual Studio) . We should all be interested in what are the factors that allow developers to flourish and then play our bit in ensuring that it happens.

Of course you have to write good code and for that you need to understand the languages you work with, but I’m convinced that you can get much further by working on the constants in our professions and not the things that change!

User experience in the software development team

User Experience (UX) design is traditionally seen as the domain of user interface (UI) design, but within a software development team it should mean so much more! UX should permeate through the whole development team. It should influence the way middle tier developers’ craft their components and the way database administrators create their tables, stored procedures and views.

Update: This article has now been published in UsabilityNews

Within a software development team, most talk of creating a good “User Experience” usually relates to creating an intuitive user interface. In the traditional sense this means;

  • The layout of the buttons,
  • The ability for the application to remember contextual information,
  • Or the intuitive nature of a web site navigation system,

but these interfaces, although important as the “face” of the application, are actually only a small part of what makes up the product.

Beyond the User Interface

A software application, like an iceberg, has a great deal of it’s complexity in the underlying structure of the program, the object model, where there are countless different members (interfaces, methods, and properties, delegates etc.) which transfer and transform data between objects and to and from the database.

While not as visible or as glamorous as the UI these are all interfaces that have users, your colleagues, whose needs must be satisfied.

On one level these “users” could be considered the most important users to satisfy because the culmination of their efforts make up the finished application, the ability for them to produce good software and the trade-offs they make in order to create the software will have a big influence on it’s character.

With this in mind the environment and the mind-set a developer works in is crucial to their ability to produce a good overall user experience. Every effort should be taken to ensure that they are focused on creating a good quality product, not in compensating for an awkward development environment or in acquiring the contextual information, from obscure code, that they need to complete their task.

Creating the right environment for UX to flourish

Every developer should be encouraged to develop this mindset; one way is to ensure that you create code that enables your colleagues to interface with it easily.

The simplest and most effective way of doing this is by naming your classes and members appropriately.

As a rough guide;

  • Your objects should be named clearly.
  • Your objects and their members should be named so that their intention is obvious.
  • Your members should exist harmoniously within scope of the class they inhabit, as well as the overall application.

When the ambiguity is taken out of the development activity, the amount of tacit knowledge needed to complete a task is diminished and the communication between team members is simplified but it’s in the subsequent phases of the project when this clarity pays real dividends. Creating an object model that is clear and expressive reduce the amount of background information that has to be re-learnt and understood before starting a development task, allowing the developer to become productive quicker.

I intend to discuss this topic further, the theme that every opportunity should be taken to reinforce a user centric mind set is, I believe, critical to the development of good products. Only by cementing the “user” in all it’s forms as an integral part of the development process will the team truly understand what is needed to create a successful User Experience.