Becoming a modern Renaissance Woman

TIL: my wish to become a programmer stems from wanting to become a renaissance woman in my field.

It’s difficult with all our advances in science to be among the top in many different fields, the same way Laura Bassi did in the 18th century for example. But I think within the field of Software Development it’s (possibly, kind of, for some definition of it) achievable.

Not in the sense that I want to be recognized as the top but I want to understand this field. Like deeply understand.

I already know a great deal about testing and realize that I’m far from knowing it all. I have some awareness of where some of my gaps are. I feel that’s more than I knew when I started out, or a few years ago. Some day I might fill those gaps and probably discover new ones in the process.

I’ve also come to understand and learn about teams and coaching. Here, I’m not as far advanced as I am in testing. It’s an incredibly vast area but barely scraping the surface has given me powerful insights already.

Coming into the world of programming and making (more) sense of how systems programmatically fit together will give me another piece of the puzzle. So far, I’ve been approaching it from the outside perspective. I’ve seen programmers struggle and I’ve helped best I could but I haven’t experienced it first hand. This is of course the most crucial piece of the puzzle since without the act of putting the software together, we’re not doing Software Development.

Not that the software has a raison d’être in itself. If we can solve the problem without software, that’s even better. I just want to contribute when the software is designed to make someone’s life easier. For example, it can be that streaming a movie is easier than going out to rent it or that new entrepreneur can charge for her goods easily.

My best guess is that my journey will take me through a few more different roles within Software Development. Or maybe rather than roles, performing other activities than testing, coding and coaching. It wouldn’t surprise me if I find myself iterating over those activities to deepen my knowledge.

It’s in that sense I see this change of career path as a part of becoming a renaissance woman. Rather than specializing in one or two fields of Software Development, I want to see as many perspectives as I can.

I find myself driven by one main question “how does it all fit together?”

Lightning planning

Some teamwork is better done in silence.

My golden rules for planning:

• I want to spend as little time as possible on the things which don’t matter.
• the goal of planning is deciding what to do, not how to do it

While a planning session can be a drawn out and tough experience with lengthy discussions, I like to keep the planning quick and full of energy and here’s one way of getting there.

Silence

Start by bringing up your work items on a white board or a table. *

Use categories: “do now”, “do later”, “never”, “I have a question before I can decide”

(Regarding the category “never“: some things are not relevant anymore and some you know will never be a high enough prio to make the cut. Just get rid of them, you’ll feel better afterwards.)

Ask participants to move items to  in silence.

If some items move back and forth between the categories, put it in the question category.

After 2-3 minutes you will have a rough filtering of the items without much effort. In my experience, half of the items in our backlog are filtered away.

Put away the “do later” items. Read though the “never” to make sure nothing important gets lost.

Questions and Answers

Now you’re left with the questions and the “do now” items.

Go through the questions (here is where you need to bring your facilitator skills and keep it short. The purpose is to get the question “do now, later or never” answered. Be relentless!

What Now?

So, finally, you’re at “do now”. Figure out how many things you can handle in the time frame until your next planning by using your throughput or velocity.

Now you want to fill those slots. If you have many more possible items than slots, I would try to avoid going through each item on “do now” and discuss them since you want to only discuss the things which you’re actually going to do. We don’t really know for sure which ones those are yet, but we can try to narrow it down.

Here you could use silence again to prioritize from most important to least important by asking participants to move the items in silence. You could also dot vote.

Double check that none of the things which aren’t in your slots is crucial during the time until next planning.

Done!

Why it works

A common mistake is to go through items one by one. There is always something to say about an item even if we agree. Especially if there is a technical challenge in solving it.

By using physical items and silence we enable the team to quickly show consensus on the things which they are in agreement on. We visualize what we need to discuss and what we don’t.

As a former tester, I put a lot of value in discussions regarding work items, the sooner the better. But in this case, I want us to agree upon which need we need to solve first, before we have the discussions on how it’s going to be done. I would say that’s a design discuss, or something for a Three Amigos meeting.

 

 

*if you already have a physical boards, this easy. Otherwise print out your cards and use magnets or write post its for them.

A planning session

The team realizes it’s time to step away from the computers and train of thoughts and head over to a conference room for the meeting. Reluctantly keyboards are abandoned, screens locked and everyone shuffling their feet like 5 year olds asked to clean up all the while the code conversations carry on well into the conference room. Until the Scrum Master interrupts.

– We have been asked to estimate this task of upgrading a component to a new version.

Everyone nods and discuss what such a change would mean and after a while dive into code on the projector. Solutions are discussed, details are demanded, implementations analyzed. The code archaeology session is well underway when someone says:

– So there are two possible solutions then?
– Yes, basically, responds one developer and continues to list which classes should possibly be modified.

The conversation carries on a little longer until the same person speaks again, carefully.

– Will the two solutions take a different amount of time to implement?
– No, that’s not likely, another developer answers while the others aren’t leaving their train of thought on the code and classes.

The person now addresses the Scrum Master instead while the developer’s discussion is getting more heated regarding the state of the legacy code they will be forced to work in.

– What kind of estimate are they asking for? I mean, what granularity, number of sprints or so?
– Yes, exactly, just to get a feeling of roughly how much time it could take, the scrum master answers.
– How long do we think it’s going to take then? This time, the person speaks a little louder, making sure to interrupt the conversation and gets everyone’s answer.
– About 2 sprint I would say, answers one person. Everyone nods and agrees and the conversation moves from bashing the old code to discussing benefits and drawbacks of the different solutions.

– So, I guess we’re done then?

The room goes silent and the person meets everyone’s questioning looks.

– If both solutions take about the same time, which is about 2 sprints and that’s the kind of estimate we are asking for, then we have our answer, right?
– You can leave if you don’t want to be here, offers a developer, clearly annoyed by the interruptions, and tries to go back the debate on which solution to choose.
– My point is that we can all leave, retorts the person, interrupting again.

The silence is tense.

– Everyone here has something they would rather be doing and we don’t even know when we will be asked to do this change. By then we will have to go through this discussion again with the same arguments and the same procedure of digging through the code because we will have forgotten about it. Our goal was to give an estimate, and we have that. Let’s go and do some work!

The conference room is left with a light, relieved step and the team is filled with anticipation of the work that will be done in the 40 extra minutes suddenly gifted to the them.

Experience report: testing dojo with entire dev team

Last spring I worked as a test lead/quality coach for 3 teams that did their own testing. I experimented with different techniques to help them further improve their testing skills. I wrote this experience in March but I didn’t get around to publishing it then which I’m doing now.

I want to share with you another way of combining testing, learning and fun

At the Agile Testing Days in Potsdam/Berlin I accidentally ended up in a testing dojo session. For an hour, 4 pairs of testers tried their skills at a buggy piece of software and received feedback about their testing. It became immediately clear to me that this was a great opportunity to improve testing skills and I decided to try it at home with my teams.

I work as the sort of test lead who provides inspiration and encouragement for 3 teams of programmers who do their testing themselves. For our domain, web development, this works well. We have developed a testing strategy together and I also help them improve their testing skills. They are awesome, committed to continuously delivering value to our customers and eager to do a good job.

I planned a testing dojo of an hour and promised candy and laughs. The response was, to my relief, positive. I wasn’t sure that they would want to spend an hour of precious programming time doing testing. I chose an hour so that it wouldn’t be too long and it was easier to find a room and a time slot.

The preparations took a while because I needed to decide on a suitable piece of software and read up on dos and don’ts for testing dojos.

Finally, the software I picked was the one I had tested in Potsdam. It was crawling with bugs and this meant that everyone would find some. I thought this would be good for a first session to make everyone comfortable. It was also small enough to be constraining but big enough to allow people to try different areas. I also wanted to have something which no one in the teams had written themselves so that there wouldn’t be any awkward situations. This meant finding external software.

The parking rate calculator – object under test http://adam.goucher.ca/parkcalc/index.php

Format for the dojo
We had the 3 roles described in the testing dojo document. Every 5 minutes we rotated. We ended with a 10 minute debrief to discuss what we observed and what was good. http://www.testingdojo.org/tiki-index.php?page=Roles

Setting up the environment
I created a few posters which I put up on the walls. They detailed the format of dojo and the parking rates for everyone to see.

I explained carefully the purpose of the dojo. I put the emphasis on the fact the purpose was to learn from each other. This means that both observers and testers learn and we should be gentle to each other. It’s not easy to sit down a new computer and start testing in front of everyone, there needs to be humility from the audience for this. And on the other hand, active and good observers are key for learning.

How was it?
First of all, we had fun! The overwhelming buginess of the software created a lot of reactions: surprise, confusion, entertainment, frustration and joy.

The programmers were a bit overwhelmed by the amount of bugs. This is the downside of using this test object. In a normal situation I would just send it back after 2 minutes, but this isn’t a normal situation. I encourage splitting the debrief into two parts: “what did you think of the software?” and “what did you observe about the testing that we did?” or even say “let’s agree that the software is crap, but what did you observe about the testing?”.

It was clear that this was an ad hoc session. There was no plan and a lot of randomness. A few people started trying to be systematic but bugs caused them to lose focus. We tried a bit of everything, here and there.

This was a good thing though. For the group to observe this randomness was interesting. It shows well of you can spend an hour testing without knowing much more than when you started. When answering the question “what would you do differently if you did it again?” the group answered that they would be more systematic or organized. We also tried to highlight some of the things that the participants had done successfully.

What now?
We will do it again. This time I want to start with creating a plan together and see the difference in an organized approach. After this I think we’re ready for code closer to our domain or maybe even our own code.

Conclusion
I strongly recommend doing this kind of exercise with your team or your peers. It’s fun, interesting and a great opportunity to pick up new skills.

 

The Leprechauns of Software Engineering

Did you know that urban legends are a part of software engineering?

Book review: The leprechauns of software engineering by Laurent Bossavit

The same way we have heard stories of kidney theft and rats in pizzas, we are surrounded by stories and factoids in our work.

Laurent Bossavit takes on a few of these bogus facts and debunks the myths. For example, the (in)famous Waterfall paper and people’s different opinions regarding it get analyzed. What did the paper really say? Was it an instant hit?

Some topics analyzed:
+ the cone of uncertainty
+ some programmers are 10 times more productive than others
+ the waterfall method was a thing
+ finding defects early is less expensive than finding them late

Despite the populistic title and simple topic, Bossavit takes on a more scientific tone in his writing. In order to really grasp some of the stories, a little knowledge of statistics is required. When Bossavit debunks a myths, he has done thorough research into scientific papers and like a detective he follows the trail of evidence to see if there is any truth to the claims. I fear that for some readers, this academic approach might not be as exciting as for others. However, it is also possible to skim through it and still get the main message.

I feel that the book is much needed. While reading it, I tried to remember when I last heard someone make the claims which are being adressed. Often, it was recently, perhaps a couple of weeks prior. Once it was even from my own mouth.

Reading this book has made me a bit more sceptical about what I listen to when people state that something is a fact in software engineering. It has also made me rethink how I express myself, talking more about my experience rather than stating things as facts. Bossavit also ends the book with a discussion, science doesn’t seem to be apprioriate for analyzing methods in software engineering, how can we work with it instead?

I really enjoyed reading The Leprechauns of Software Engineering. For me, it was exciting to follow the trail of evidence (or lack thereof) and see the claims debunked. I also think it could be good book club material with interesting discussions to follow.

Helpful RUP

From RUP, I used the “Vision document” and the “Risk list” and it felt like a great help!

Do you remember RUP, the Rational Unified Process? Have you heard how frowned upon it is nowadays? People joke about using it and tell horror stories from RUP projects. Probably the same way you’ll hear horror stories from failed SCRUM projects in the future.

I never used RUP for more than a school project but there were two things with it that I really liked and I felt a need for those today.

I’m planning a course in Agile Testing which I will be holding in February this year*. It was hard to get started, the usual “Where to start?”-paralysis. Realizing that I needed to keep my goal in mind to do a successfull course and that there were a lot things that scared me about this, I pulled up two classic artifacts.

The vision document (written on an index card) for my course is “The participant should feel the inspiration and the courage to work with quality together with the team”. After writing it down I reflected a bit on what is inspiring and what inspires courage. I need to keep this is mind when putting together the topics and exercises we’ll do.

My risk list (which also fits on an index card) includes five items like “too abstract”, “not enough time”, etc and each item has an action that I can do to mitigate the risk.

Having produced these artifacts feels good because I now have a plan to deal with my fears and I have my vision written down which will help me stay on track. When asked the question “will your course include X?” I can think of my vision and decide wether it is relevant to fulfill the vision or not.

So don’t be affraid to pick techniques from different places. Even from RUP 🙂
* This is part of an innovation program that we have at Citerus. Anyone can spend a few work hours preparing a pitch for an idea they would like to develop. I got to see my idea through which meant more available hours to get to try something new.

“Has software development gotten too complex?”

While doing my cleaning duty at our daycare I finally got around to listen to the .Net Rocks panel discussion on the topic “Has software development gotten too complex?”

The first thing that hit me was the fact that a lot of the panel members and the audience argued that there were too many tools and too many options. I understand how this can be perceived as an issue but it seems like an odd argument to me. What would be the solution to such a problem? Putting a restriction on the amount of tools that people are allowed to develop?

There are a lot of tools out there and picking the right one might be hard. But the truth is that you don’t need them all to produce good software. The problem might be that people are feeling an obligation to use as many tools as possible, or tools that are too complex in themselves for a particular problem.

The show raised some other thoughts as well. We’ll see if I get them down “on paper”.

Confirmation

Lately I’ve been receiving confirmation that the title I chose for my blog really is something that want to aspire to.

First, a talk with my colleague M. I wanted to know what the big deal with releases is. Since I keep hearing about release configuration and the company that I work at has hired a release manager it seems to be something very complicated. The manager of our IT departement tried to assure me that adding configuration management made their code testable. I failed to understand him but smiled and looked happy (it wasn’t a good moment for a discussion).

The answer M gave me was that it shouldn’t be a big deal. He then looked me in the eyes and added “And don’t let anyone tell you otherwise.”. It makes sense to me that if people make this huge deal about releasing code it turns into something scary and difficult. And there is a risk with that, it turns into something you would rather do as little as possible.

The conclusion, releasing code should be simple.

Another hint was a podcast from .NET Rocks that I listened to on my bike ride to Old Campus. The topic was James Kovacs on Convention over Configuration. The message was simple: by using conventions rather than configuration setting things up can be done in a much simpler manner. You don’t need to worry about the “plumbing” in the same way. Also it makes your systems easier to test since it is possible to test the convention and then be assured that it is working.

Here, implementing code should be simple.

As for me personally, I want to have the time for my 2 year old, roleplaying Star Wars, listening to podcasts, working out, sewing, etc, I don’t have the time or energy for complicated.

The perfect process

It is seems that everything is always about adapting.

There is no perfect process for software development, it is always up to the people to perform their best. With enough competence, it doesn’t matter which process you use, and without it, you won’t grasp the process.

Or is there an area in between where the process is helpful?

On an individual level perhaps, but for a group some will be above the process and some below.

So how do you raise the competence of the ones who need it and how do you keep the ones who “get it” from stumbling on the process?

Words of wisdom

On my Software Testing and Metrics course we had a guest lecture this week. It was a tester for Nasdaq OMX and he told us a little about how testing works in “real life”.

He started of by reminding us how the price tag on a defect rises dramatically with time and spent a  great deal of time on the fact that a lot of defect can be found in a matter of seconds or minutes.

A few techniques enabled this. The first he bought up was pair programing. Stimulating different sides of the brain in the two programmers, pair programming has (possibly) a positive effect on the correctness of the code. Both for small mistakes such as uninitialized variables and larger as design flaws. Of course, pair programming isn’t a simple technique, it requires a lot of factors to click for it to be as efficient as it is on paper.

A great deal of time was spent discussing Test Driven Design. He talked about a study done at Microsoft and IBM were two teams were given the same task and one worked TDD and the other didn’t. It turns out that the team using TDD worked 15-30% slower BUT after a time of use their code turned out to have 40-90% lessdefects. 90%! Amazing results.

Also something as simple as keeping the developers and the testers in the same room helped uncover defects in a quick way. Making it easy for testers to discuss the code with the developers meant that interpretations problems could be discovered and solved, making both the software and tests better.

And then he talked a lot about tools. How Continuous Integration could help you make sure that the code you checked in really worked and didn’t break anything else. How Static Analysis could give you warnings about possible defects. How code coverage helped you make sure that there isn’t any untested or dead code.

He finished the lecture by giving us a demo of how a test case at OMX could look like.  We looked at almost 2000 lines of test code for a single requirement…  Using this he stressed the importance of using code conventions and test case traceabilty. It was imperative that each test case contained a reference to the requirement tested.

I asked some questions about the size of their company. They had about 8 developers and 10 testers and were trying different project processes without finding one that suited them yet. They made sure that testers and developers worked on the same features.

Exciting stuff for a wannabe-tester. 🙂