Integrating with Users

Somewhere along the line, to a greater or lesser extent, all software is integrated into some kind of front end to allow users to interact with it and benefit from the value it can provide.

Too often this value is masked under a shroud of a confusing UI, causing users to fail to see this value because of what they perceive as a bad experience using the software.

It isn't enough to create a well crafted, well engineered piece of software without also putting as much effort into how the final piece of integration will be achieved, integration with your users.

Don't Astonish

They're certain noises that you don't want users to make when they are using your software. Some of these are obvious, you don't want shouting, screaming or swearing to be heard, but we also don't want any kind of puzzlement or astonishment.

Users do have to go on a journey of discovery when using any new piece of software, they need to learn what its capabilities are and what value they can bring. But users should never need to be trained to use a piece of software, this process of discovery should be one of self discovery.

If you find yourself having to construct tutorials, FAQs and help sections to explain to users how to operate your software then your preventing them from going on this journey.

The majority of your users will not be prepared to put this level of effort into learning how to utilise what you've built, your hard work in developing features will simply never be discovered.

Instead we should simplify wherever we can and let users stumble across the value we can deliver without expending much effort of grey matter.  

Don't Reveal Detail

Writing software can be a difficult and complicated matter, sometimes we are faced with solving challenges related to systems integration, legacy code bases or sub optimal implementations.

All of these problems must exist in the shadows, users should never be expected to be part of the solution.

These complications of implementation shouldn't be allowed to affect user experience, if a feature cannot be implemented to provide an acceptable user journey then we should question whether it represents any value to the user.

Users can be very fickle and don't forgive valiant attempts by developers to implement a feature despite the technical challenges if it doesn't sit well with how they want to use the software.  

Don't Find a 3rd Way

Sometime there is what is correct and there is what people actually want or understand.

Users like familiarity with what they have seen and used before, it may be that what they are familiar with is in some way flawed.

Just about every platform that you will use to deliver your software to users will have these conventions and perceived wisdoms.

I would never want to discourage anyone from trying to innovate but to go against these conventions of how people expect to use software on a platform can be fraught with danger.

Even if you think your new way is an improvement in order for users to not be put off by the unfamiliarity of what your presenting to them it needs to be a significant improvement.

Be cautious when innovating with new ideas for user experience, users can all too quickly dismiss something new it it doesn't match their expectations based on what has gone before.

Users are often difficult things to predict and we can be left frustrated when something that we've put a lot of time into and believe is dismissed or misunderstood.

But ultimately the user is always right even if for no other reason then you can't force people to use your software.

As with most aspects of engineering simplicity should always be something to strive for.

We may inevitably have a certain amount of complication happening under the hood but our user experience should be an effective shield from the user ever being aware of any of this, and instead be impressed by the apparent magic we are able to produce. 

Don't Write More Code

As strange as it may seem we aren't in the software production business, we are in the solution delivery business.

What I mean by this is we shouldn't measure our effectiveness by the amount of code we produce but by the number of solutions we deliver.

We should actually consider code a necessary evil in delivering these solutions with it counting more as a liability than an asset.

Costs of Production

If viewed as a commodity code is pretty costly to produce, developers are highly skilled well paid people and good code can take time to engineer.

If we define an implementation that requires a lot of code to be written we are increasing our costs and putting our deadlines at risk.

We need to make sure that developers time is spent on writing the code that provides the features we really need, not re-inventing the wheel or falling into the not invented here trap.

The essence of this approach is re-use, whether this be utilising 3rd party code that does what you need or by recognising when you write code of your own that what you're writing will be the answer to a similar problem in the future, effectively reducing the time to provide the solution the next time round.

Whenever you find one of these re-use potentials your reducing your costs and making it more likely that you'll hit your deadline. 

Production Defects

Whenever we write software we are usually writing defects at the same time.

While I wouldn't suggest that its impossible to produce a small piece of code riddled with bugs or a large piece of perfectly bug free code, there is undoubtedly a relationship between the amount of code we write and the number of defects we create.

This is not only a problem because we don't want to ship bugs but also we create a vicious circle of even more developer time, which we've already established as expensive, being spent on fixing the issues. 

Re-use once again is our friend, by re-using code, especially well tested code, we can ensure that we build our software on strong well understood and proven foundations, reducing the amount of new code that is likely to cause defects.

Maintenance Not Guaranteed

Code can rot if not maintained, this can be because of constant change to deliver new features, hacks or patches being applied or not being kept updated with changes elsewhere.

The more code you have the more rot your going to see, and once again this brings us back to the time and cost of having to maintain and fix that code.

Yet again re-use can help us, by ensuring we are using the same solution whenever we encounter the same problem we reduce the amount of code that needs to be maintained.

If we discover a problem in a library or package we can fix it once and feel the benefit in every other code base without expending any more effort or cost.

Its very easy to fall into a trap of engaging in engineering software for purely technical reasons.

We are enthusiastic about what we do and gain pleasure from doing it, but our industry is not about production lines. We aren't employed because of our ability to produce code, we are employed because of our skill in utilising software to achieve business outcomes.

There doesn't have to be a relationship between the amount of code we produce and the number of outcomes we achieve.

Think of software engineering as a constant process of refinement rather than as a means to bring more code into the world.