Tag Archives: developer tool kit

Why we need a better tool set for building software

At the end of my last blog, I asked, “So – why is technology flawed? Why not build it well in the first place?” There could be several reasons, today I want to discuss just two of many:

  • Limited types of people in the industry: The software engineers do not always understand what is needed because they may not understand the people who will use the technology. Because of this they may deliver software that is the product they themselves want to use. This means technology can be biased towards the type of people who are already software engineers.
  • Automation bias and poor decision making: The software engineers and the non-engineers on the project team may have a toolset that does not enable them to make good decisions. Yes, all the flaws in technology that I talked about in the previous blog are also true for the tool set that software engineers use. The tools are intended to help decision making in the project. Is the software ready? Has it been tested? Does it work? Are there any risks in delivering it now? But if the tools are flawed, and hard to use, people are more likely to make poor decisions with poor outcomes. That will lead to flawed software and potentially an ugly UX for everyone else. Note that technologists and software engineers also suffer from software with flaws in it, software that is hard to understand, and tools that prompt them into automation bias.

Two sayings that come to mind here “a fool with a tool is still a fool” and “a poor workman blames his tools” and it would be easy to stop at that. But the industry has spent too long building up some traditions around old mind sets and old tool sets that favour old ways of doing things. If technology and software is to serve and reflect the widest population, to everyone’s benefit, then the teams need to reflect society. If the teams reflect society, then the tool set needs to be easily used by a wider range of people, not just the obvious technologists.

As Seth Godin remarks in [Demand Guardrails] “If peer pressure and short-term urgencies set us up to do things we regret, we come out ahead when we support cultural changes that remove that peer pressure and lessen those short-term urgencies.” This blog is a call for a change to the tool sets used by software engineers, to make them easier to use, easier to understand, and supportive of good decision making that tends to a beautiful UX for everyone. We need to support cultural changes in the world of software engineering that remove the peer pressure of being the same as we’ve always been. We need to support cultural changes that remove short term urgencies that stop us mending out tool set. We are the cobblers, and we are the cobblers’ children with no shoes.

Old tools sets are hard to use. Early sewing machines required skills with the machines that are not needed by modern machines; a sewer today can concentrate much more on the project, and less on the tools. Early cars were hard to drive, with starting handles and double de-clutching to master. Modern cars are easy to start, easy to drive, automatic gears and power steering. The driver can concentrate on the journey and the destination. More people can use a sewing machine now, and make their own clothes. More people can drive, and have the independence to make journeys. [Rise of the female petrolhead, Car electric starter, Treadle sewing machine difficulty]

I would like to move software engineering tool sets to beyond the treadle machine and the car with a crank handle starter to a modern, smooth system where automation and tools serve the project team rather than being a hindrance. This will address both the problems above:

it is like working with something designed to be used by a 12-year-old boy in his bedroom in the 1980’s”.

“Why would I want to use a tool called Github?

But this is not just a problem about gender or culture; the tools are themselves flawed and old-fashioned.

  • Tool flaws: IT teams are themselves beset with the same problems and frustrations with the tool set they have to use, and this leads to the release of highly flawed software. Many IT tool sets are almost deliberately arcane and are gender biased. Many become “shelfware” – purchased but hardly ever used. Others are used with automation bias – the results are wrong but are treated as correct. Here are some more quotes from developers, testers, and researchers about flaws in tools

Developer: “I spend 50% of my time wrestling with the technology instead of solving the problem I am working on” Quote from WII meeting

Software tester finding decision making not supported by IT toolset: “The test tool marked all the tests as passed except 1, but in fact none of the tests marked “passed” had actually run” Quote from Fewster and Graham “Experiences of Test Automation”

Problems with customer support tools: “Ethnographic research paints a sad picture of the current state of the ITSM market.   …vision is to build a solution designed for humans, not processes” [http://blogs.ca.com/2016/01/27/moving-itservice-management-to-the-21st-century/]

Evidence that developers do not find tools easy to use: “…so now I wanna know why raising a string exception is bad. Like what should I be doing instead? Since it thinks it’s a problem. And so none of these really help me…” (Why Don’t Software Developers Use Static Analysis Tools to Find Bugs? By Johnson, Song, and Murphy-Hill).

Evidence that tools do not work for IT people “…a lack of consideration for how people work and think … basically it’s still the mindset that the human adapts to the computer, not vice-versa.” (A Taxonomy of Tool-Related Issues Affecting the Adoption of Model-Driven Engineering by Whittle, Hutchinson, Rouncefield, Burden and Heldal)

In the previous blog I said: The reasons that technology and software may prompt poor decision making include defects in the software […or that it…] may function correctly, but in a way that does not aid people in making good decisions. … dealing with frustrations, defects and consequences of poor engineering is a bad experience for the people using the technology; a flawed, ugly UX. That is true for tools used by the teams delivering software, and is a key root cause for the problems we all experience with delivered software.

What I will propose in my next blog is a solution to these problems.

Quilting and hacking

Two blogs to which I subscribe had new posts this week, and they just fitted together:

Now I know sometimes I can be a little obsessive about the analogy between sewing and IT; the need for a workbox, the need for new ways of using old methods, the way the projects are similar… but I urge you to read them both and compare.

A project works when you understand the materials you are working with, how they fit together, and how you can modify them. Repurposing happens with fabric and with code. Hacking can be a good thing – with code and with fabric. But you need to understand the pillars for success. The Googletesting blog suggests to me:

  • refactoring old code so you can reuse it
  • consistent formatting giving patterns that you can follow and
  • use of structure and architecture to hold everything together

Knitnkwilt suggests to me

  • working with what you have got by reusing/repurposing old things
  • using a consistent pattern framework to hold the design together and
  • enhancing the old with new structure/fabric.




UX? What about TX for Test Automation?

Test automation is intended to increase speed and accuracy of information about the SUT partly by allowing engineers to improve the speed and usefulness of their communications.

The best possible interfaces and user experience for the person testing are required to support this otherwise the use of automation will decrease rather than increase velocity of projects.

If the speed and accuracy of test information provided to teams is lowered, with poor test reporting and inaccurate decision making, engineers and managers will become frustrated. It may even lead to disaster.

Good automation tools will help us make good decisions about the SUT and maximise the value of the limited time we have to deliver software products to market. Poor automation tools will delay decision making, increase the likelihood of errors of judgement, and they frustrate both engineers and managers.

Current practices (agile, build pipelines, devops) arise from a need to address delivery speed and accuracy as well as engineering quality. But automating the tests and then forcing people to spend time inaccurately and slowly interpreting the outcomes simply is not cost effective or helpful.

There are many examples of poor interfaces and tools contributing to, or even forcing, humans to make bad, even fatal decisions. Examples such as the London Ambulance Dispatch system (http://bit.ly/1tr2TJZ), and the EU Farm Payments online application system (http://bbc.in/1xEoUE3) show us that poor interfaces can be time wasting, expensive and dangerous.

This matters for test automation because, although automation tools are written and serviced by engineers, the people who use the automation can be non-technical for example user acceptance representative, product owners, business sponsors, managers or end users. Does the information they get from the automation and provide to engineers improve in speed, accuracy and usefulness as a result of the automation or not? What will maximise our ability to get the most from the test automation? What will maximise the accuracy and usefulness of the information provided to engineers, managers and others?

There is a need for TX for Test Automation: that is, the Test Experience for those people who will request, design, and review the results of the automated tests and monitoring. This requires information design and delivery (arguably the purpose of our industry).

Attention to detail “front of house” for the UX for customers and end users can be extended behind the scenes to TX for the engineers, benefiting all. TX can be improved, by consideration of the UX for the automation tool and the tests so that methods and lessons from User Experience Design (UXD) and User Experience Testing (UXT) may be applied to test automation.

We need to consider human factors (as the engineers are human too) as well as the support of improved decision making around quality, speed and accuracy of responses to issues.

My three key points?
– Test automation requires consideration of the UX for the tool and the tests;
– People who use automation might not always be technical but they are always human;
– UXD and UXT for test automation supports improved decision making and quality.

(This post also appears on my “Isabel Evans Writing” blog.)