Listen to the old ones, or re-invent the wheel

Some while back I read a blog entry from Jason Gorman on Wheel-driven reinvention. His core statement is, that there is nothing new in the world of software development. When you start to trace back any common hype in the software industry, you will most likely end up in the 1960s or 1970s finding the core idea raised by that time. When I first read his blog entry, I was going to write a follow-up describing how little the great old ones help us understand their solutions to the problems of the software industry in the last decades or so. Since I know that I had to incorporate Gorman’s thoughts into my models I decided to postpone it a bit, and get some time to think over it.

There are just a few professionals who actually did what I was claiming, but the more striking point for me is how little time we spent listening to them. One excellent example of a great old one is Gerald M. Weinberg, who worked on project Mercury for the NASA, and was part of the first testing teams when the latest hype was to do testing independently back in the 1970s. Recently I came across a paper from Edsger Dijkstra, written by hand. Into that line fits also Brook’s Mythical Man-month or the No Silver Bullet article. And I know that there are other great examples of great old ones, to which we should pay attention, in order to learn something new.

That said, I read a blog entry from James Shore yesterday on Large-scale Agile. He put up a great effort to describe how to combine the ideas from Scrum and the ideas from Kanban together to scale Agile up on a larger basis with sub-dividing teams. His ideas are interesting, and I gave up half-way through trying to understand all of his premises. Remembering back my math teacher in school when I showed him a proof that one equals two, he stated: “When working from a false premise, you can show anything.” This is even true in writing.

How come there is nothing new about large-scale Agile? The textbooks on Scrum just mention the Scrum of Scrums, but not how to apply them. XP and Kanban just work on smaller teams, so he’s actually writing something new. Really? No. Obviously not. the Crystal methodologies, and recommendations for large-scale Agile. Thought, he stated that there is a barrier to Agile and their light-weight methodologies at project size of about 500 persons. Scaling Agile up, though comes with a prize. Larger teams need other communication channels for example. You may put a team of 12 into a single room. The team can work up with osmotic communication. On a 500 person project, you may have difficulty to find a room large enough, and obviously not everyone will be able to overhear the conversations of all colleagues. There are other penalties you have to pay for scaling Agile up. Whole-heartedly I recommend reading his book on Agile Software development.

Additionally, what I learned from Cockburn is the notion of a sweet-spot of Agile methodologies. The lightweight nature of Agile methodologies has a sweet-spot on a lower team-size with fewer effort put into ceremony overhead for hand-offs. When increasing the team size, you automatically get a larger communication-need. There are non-linear increases in the amount of possible communication channels among team members, as well as slower communication channels like informations flowing across different rooms. That said, if you don’t fulfill the need for more communication, you may find yourself set up for Agile failure.

There are many other factors which need to be increased for the larger team-size in a non-linear way. In case you’re searching for an answer on these questions, I recommend to read all of the following book

  • The Mythical Man-month from Frederick P. Brooks Jr.
  • Quality Software Management Volume 1 – Systems Thinking from Gerald M. Weinberg
  • Agile Software Development – The Cooperative Game (2nd edition) from Alistair Cockburn

Listen to the old ones, or re-invent the wheel.

Ethics in Software projects

Personally, I love to relate different aspects from other areas to my life as a software professional. Today the aunt of my wife celebrated a birthday, and I got the opportunity to overhear a discussion between my father-in-law and an uncle from my wife, who are both truck drivers. Since I read Secrets of a buccaneer-scholar, I became aware of combining different areas of my life together to learn something new.

Now, German laws demand high discipline from drivers on the road – especially truck drivers. There are given rest times for truck drivers, regulated by the local police officer. These laws evolved over time, to protect innocent truck drivers and other traffic participants from fatal injuries caused by drivers with too few sleep. There are other regulations that protect trucks from getting off-track, especially on the German Autobahn, where truck speeds of 100 km/h are usual – and cars drive with as much as double this speed.

So, working as a truck driver puts a certain challenge on you. You want to deliver your wares to the destination and hit back home. Your boss wants to deliver the wares to the promised date. Traffic jams, alternative routes, and other variables may put the predetermined schedule from your boss at stake. Today
I learned that it is common that the boss will then ask the drivers to skip their rest times.

But wait, what has this to do with software development? Well, if there are delayed deliveries from third-parties, shortcuts to requirements and/or design, among other variables, your project will be put on pressure. The predetermined project plan may become out of date. As the truck drivers’ boss, your project manager may ask to skip testing.

So, what is different in the truck driving part of this analogy is the fact that there is a police checking for too long driving periods. The German law then enforces penalties to the truck driver for giving in to the demand from their boss, so they may even lose their drivers license in extreme situations.

Seriously, I doubt that most projects would deliver untested software, if there was a project police in place, that would charge penalties from developers and even project managers for skipping testing. Sure, an overtired truck driver may deliver their goods on time in 90% of the cases, but if he just naps in front of the steering wheel once, and ends up in a massive traffic accident, the results will be dramatically fatal. The same may as well go for some software projects. However, avoid to give in the temptation to say “my project won’t cause fatal accidents, if I skip testing.”

If you didn’t get my main point, I would like to finally point you out to a fable about testing from Gerald M. Weinberg. His granddaughter Camille got the point from it at the age of four, can you get it, too?

Configuration unit tests

James Bach encouraged me to think more thoroughly about the ideas that I came up with. In general for most ideas I try to give credits to the people who made me come up with it. While thinking over it, I didn’t know whom to contribute the idea of configuration unit tests, and I think I took more than idea to generate this one. So, let me introduce you to the context in which unit tests for product configuration makes sense, and the approach we took on it.

Continue reading Configuration unit tests

Scrum Norris

Yesterday evening there was a thread of scrumnorris going over twitter. Since these messages were in German, let me translate them.

  • Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
  • Chuck Norris can do 6-month sprints.
  • Chuck Norris wears Timeboxershorts.
  • Chuck Norris does not move story cards, he moves the taskboard.
  • Chuck Norris does not estimate, he knows.
  • Chuck Norris pairs alone.
  • Chuck Norris starts project with a Roundhouse-Kickoff.
  • Chuck Norris is allowed to appear late at the stand-up.
  • Chuck Norris sits on the stand-up meeting.
  • Chuck Norris has implemented everything at the planning meeting.
  • Chuck Norris does not estimate user stories, user stories estimate him. (This doesn’t translate well.)
  • Chuck Norris writes the code first, then the test.
  • Chuck Norris is not afraid of bugs, bugs are afraid of him.
  • Chuck Norris does not do Kanban. He does not know limits.
  • Chuck Norris does not pull, he pushes.
  • When Chuck Norris says “done”, then it’s “done”.
  • Chuck Norris does not deploy, he develops on the production environment.
  • Just Chuck Norris knows, that a real burn-down requires napalm.
  • Chuck Norris has no burn-down chart. Around him everything is already burnt down.
  • Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
  • Chuck Norris does not prioritize the backlog.
  • Chuck Norris takes two baby-steps at once.
  • Chuck Norris does not use test-driven development. Chuck Norris always drives.
  • Chuck Norris is the prioritized backlog.

Any additions?

Writing automated business-facing tests

Since I work in a more traditional orientated environment, I’m facing some questions regarding the usage of test frameworks such as FitNesse, Robot Framework or Concordion. The biggest problem I hear very often is to start implementing fixture code before any test data in terms of test tables or html pages is available. Directly the scene from J.B. Rainsberger’s Integration tests are a scam talk comes to mind where he slaps the bad programmer’s hand. Bad! Bad, bad, bad! Never, ever do this. So, here is a more elaborate explanation, which I hope I may use to reference to my colleagues.

So, the first thing is to pick up the classics on the topic and check the documentation about it. So, let’s start with the classic FIT for Developing Software. So, the structure of the book is separated into a first part mentioning the table layouts, in the second part goes into detail about the classes for the implementation. So, Ward Cunningham and Rick Mugridge seem to follow this pattern. Great. Next reference, Bridging the Communication Gap. Gojko introduces there specifications workshops and specification by example. Both are based on defining the test data first, and later on automate them. This helps building up the ubiquitous language on the project at hand.

But there is more to it. Since test automation is software development, let me pick an example from the world of software development. Over the years, Big design Up-front has become an anti-pattern in software development. Though there are some pros to it, on the con-side there are that I may try to think about each and every case which I might need for my test data, but I may be wrong about that. So, just in case you are not from Nostradamus’ family, thinking about your design too much up-front my lead to over-design. This is why Agile software development emphasizes emergent designs and the simplest thing that could possibly work. Say, if I work now on ten classes, which I completely do not need when the test data is noted down, then I have spent precious time on building these – probably even without executing them. When later on the need for twenty additional classes arises, the time spent on those initial useless ten classes cannot be recovered to cope up. Additionally these ten classes may now make my suffer from Technical Debt, since I need to maintain them – just in case I may need them later. Maybe the time spent initially on the ten useless classes would have been better spent on getting down the business cases properly in first place – for those who wonder why your pants are always on fire.

Last, if I retrofit my test data to the available functions in the code, I have to put unnecessary detail into my tests. The FIT book as well as the Concordion hints page lists this as a malpractice or smell. For example, if I need an account for my test case and I am retrofitting it to a full-blown function call which takes a comma-separated list of products to be associated with the account, a billing day, a comma-separated list of optional product features and a language identifier as parameters, I would write something like this:

create accountmyAccount product1,product2,product3 5 feature1,feature2,feature3 EN

When I can apply wishful thinking to my test data, I would be able to write it down as brief as possible. So, if I don’t need to care about the particular products and features sold, I may as well boil the above table down to this:

create accountmyAccount

In addition to this simplification think about the implications a change for create account in the example above would have, when I need to a add a new parameter for example a the last billed amount for that account. If I came up with six-hundred test tables by the time of introduction of this additional feature, I would have to change all of those six-hundred tests. This time for changing these six-hundred tests will not be available to test the application. Wasted – by my own fault earlier!

In the end, it boils down to this little sentence I used to describe this blog entry briefly on twitter:

When writing automated business-facing tests, start with the test data (the what), not the fixture to automate it (the how). ALWAYS!

Deliberate Learning

Today after two weeks of reading, I finished Secrets of a buccaneer-scholar from James Marcus Bach. I was amazed on how he describes my attitude towards learning. Over the course of the last ten years I had always believed in more traditional ways to get educated. Well, when looking back at the education I got in school and the education I got at the university, and reflecting it over the stuff I need now on my day-to-day work, there is little that I have learned in those more traditional systems that help me now. Maybe ten percent of it does any service to me today. The remainder I learned myself ever since I started to work at a software company as a software tester – right when I didn’t know anything about testing software and how complex that field even is. This passion for learning has always driven myself and helped me get further ahead. When looking at my colleagues I was amazed that I seemed to be the only one, who was practicing self-education besides their day job. A key attitude I have built upon early on is the attitude for life-long learning – and I live it.

Now, reflecting back on the last four weekend of Weekend Testing in Europe, I noticed a pattern and a relationship to self-education – or buccaneer-scholarship how James calls it. Remembering back on our first session we had an online image processing tool and were asked to test it. There were two or three people who had experience with image manipulation, and the remaining three or four did not know anything about it. Since the mission was provided at the start of the session, this meant that no one really knew what was going to happen to prepare. Since no one dropped out of the session either, all participants were very, very eager to learn something new.

Indeed, when you face a situation which you don’t know anything about, some may react with fear about it. James taught me from his book the most valuable lesson: A buccaneer-scholar is not afraid of new situations. Even when you just now a tiny little piece of information about the product you’re going to test, or the project you’re asked to work upon, your deliberate learning attitude can and will help you. There is no big impediment to get to know something new. Maybe it gets you out of your comfort-zone, but imagine all the stuff you will know in addition to now. You will be able to make associative connections to stuff you already know. This is how your brain works. By making new connections, you may also reflect on stuff you already know and learn new things about that, either.

Deliberate learning can help you become used to learning as a competitive advantage. I see this happening for myself, I see it happening for James Bach (take a look on the videos on his buccaneer-scholar site), and I know that it may very well work for you as well.

Happy learning.

Burning Issues of the Day – Revisited

Michael Bolton published his speech from EuroStar 2009. It’s humorous. In fact there is one story line which hit my face when I viewed his presentation some time earlier.

  • When a manager asks you to show him your test cases, ask him to show you his management cases.
  • When a manager asks you to show him your test scripts, ask him to show you his management scripts.
  • When a manager insists that every test should have an expected, predicted result, ask him if every management action should have an expected, predicted result.
  • When a manager insists that we lower the cost of testing by bringing in test automation, ask if we can lower the cost of management by bringing in management automation.
  • When a manager wants to evaluate testers based on “defect escape ratios”, ask if we can evaluate management by “bad management decision escape ratios”.

The series seems to be inspired from James Bach as can be seen on the slides.

The interested reader will of course immediately notice there are some points left out. So, let me introduce them here:
When your manager asks you how many percent of your test cases were finished, ask her how many percent of her management cases were finished.

Testing, just like software development, is an activity, which is highly influenced by humans, individuals, their intrinsic and extrinsic motivations, abilities, and contexts. If every testing activity was highly predictable, then how come there are so many of those predictable models? How come there are several schools (in the Kuhnian sense) keeping on arguing over it? If we could identify all relevant quality issues up-front, why wouldn’t we avoid problems in there in first place?

When your manager asks you how many testing is planned to be left, ask her how many management is planned to be left.

Testing is a human activity and in most cases it is hard to predict how long it may take. There are a lot of factors that influence how long a previous planned testing activity may take. Instead, you should ask: “do we have gathered enough quality-related information about the product in order to make a ship/not-ship decision?”. But, leave that decision to the management.

When your manager asks you about best testing practices, ask her about best management practices.

Don’t do this. They might answer your call.