Step Away from the Tools

Posted on March 4, 2011 by Liz

This may seem odd coming from someone who spent months coding a BDD tool, but seriously… put it down.

Step away.

BDD has taken off in the last few years, and lots of people have approached me for help. Many of the questions I get are along these lines:

  • These don’t seem worded quite right. What do you think?
  • How can we stop these scenarios being so brittle?
  • How do we use our BDD tool to do <this kind of testing>?
  • We’re using a BDD tool. How do we get our analysts to help us?
  • How can we avoid all this duplication in our scenarios?
  • What do we do if the business aren’t interested in BDD?

Don’t start with BDD, and definitely don’t start with the tools.

Start by having conversations, engaging both testers and business stakeholders or their proxies (analysts are good here). If you can’t have those conversations, stop. You can’t do BDD. You might be able to write some scenarios or some acceptance tests, but they’re likely to be brittle and it’s unlikely that anyone will be interested. Here’s why.

BDD is focused on discovery.

Dan wrote a blog post introducing Deliberate Discovery some time ago. This philosophy is at the heart of BDD. There are things about your domain that you don’t know, or you’ve misunderstood, or that nobody’s thought of yet. By talking through examples in groups, the chances of uncovering these gaps and misunderstandings is increased. BDD provides a language – “Given <a context>, when <an event happens> then <an outcome should occur>” – which helps to prompt questions around whether the scenarios are accurate. It’s meant to help you have conversations, not replace those conversations entirely.

Conversations help us discover things.

You don’t have to stick to the BDD format to have those conversations. The language is a guide, and serves well for automation. Chances are that if you can’t phrase your discoveries in that way, you won’t be able to test the understanding later (though you might be able to explore some more). This is because tests start from a particular context, perform some events and verify some outcomes.

There are other things than scenarios which you can discover through conversations, though. You can listen to the language which your business stakeholders use. You can ask questions about the words they use and gain an understanding of the domain, which may not be used right now but will help you design your code in a way which allows changes to be made more easily, later.

The conversations often help to engender trust between stakeholders and the development team. When someone indicates that he wants to understand me, and plays back that understanding to check its accuracy, I am reassured that he genuinely cares. I tend to be more patient in my explanations, more likely to come join him in his place, wherever it is, and more likely to check back later to see how he’s doing.

Business stakeholders are just the same, only busier, and harder to get hold of. But that’s why they call it business.

BDD isn’t the only way to do testing.

In fact, BDD isn’t even really about testing. It’s just a way of capturing those conversations which happens to provide some tests, and lifts some of the burden on the testers. If you want to run additional performance tests, exploratory tests, or even record some tests, it doesn’t have to come under the BDD banner. It’s perfectly OK to do BDD and test things as well.

BDD isn’t about the tools.

You don’t need BDD tools to do BDD. A few of the projects I’ve been on now have run up a small DSL which they found perfectly easy to maintain. The only reason to use English-language BDD tools is because it helps to engage people who can’t read code (and I’ve seen senior business stakeholders perfectly happy with code-based DSLs before).

Natural-language BDD tools introduce another level of abstraction. They make scenarios harder to maintain. They can introduce ambiguity. If they don’t have auto-completion, it’s hard to see what steps are already in play. It’s even harder to see what steps can be deleted, and don’t need to be maintained. Don’t use natural-language BDD tools unless they give you significant other benefits. You can capture scenarios from conversations just as easily on an index card.

Write fewer scenarios.

Most of your code will be covered by just a few scenarios along the lines of, “Normally everything works like this, and then in this context it behaves unexpectedly, like this.” Use those tricky scenarios to cover the normal behaviour wherever possible, and focus on making sure that the code is well-designed.

Another way to make scenarios maintainable is to make sure that the steps are phrased at a very high level.

Higher than that.

If your scenario starts with “When the user enters ‘Smurf’ into ‘Search’ text box…” then that’s far too low-level. However, even “When the user adds ‘Smurf’ to his basket, then goes to the checkout, then pays for the goods” is also too low-level.

Think about the capabilities of your business. What does it allow your users to do? What value do the stakeholders get from it? How does it actually make money?

You’re looking for something like, “When the user buys a Smurf.” Now you’ve got the money, what differentiates your business from everyone else’s? Do you advertise other Smurf-related products? Find everyone who’s bought a Smurf and show what else they bought? Offer discounts for Smurf holidays?

By thinking about the capabilities of the system and the goals of the business stakeholders, you’ll find ways to phrase scenarios which keep them maintainable, no matter how the GUI changes. The conversations you have will help you to identify those capabilities and goals.

The rest of scenario maintainability is mostly about removing duplication. Separate steps into particular concerns, like “admin”, “browsing” or “purchasing”. Put screens or pages into their own objects (thank you Simon Stewart and WebDriver). If you find your scenarios are getting unmaintainable, pay them the same kind of love you’d pay your code. They’ll probably be around longer.

Assume you got it wrong.

Part of the Deliberate Discovery ethos is that there is always something we don’t know we don’t know – second order ignorance. No matter how many scenarios we have, our understanding can still be wrong. The only way to discover this is to get feedback. Showcase what you’ve produced. Ask people to use the system and see how it feels. The earlier you can do this, the quicker you’ll discover that there’s no silver bullet. You will never get everything right – even if you analyse everything up-front, Waterfall style – and BDD is no exception.

Have enough conversations to know how to get started. Find out where the riskiest bits are, and where the system behaves unusually. Chat. Discuss. Discover. Work out how, and when, you’re going to get feedback on the work you’re about to do.

Then, and only then, reach for the tools.

Posted in bdd, testing | 20 Comments

Why I didn’t sign the Software Craftsmanship manifesto

Posted on January 14, 2011 by Liz

I’ve been reading Dan North’s post on programming as a craft, and Adewale Oshineye’s response. I also don’t view programming as a craft. I believe that programming is merely the vocabulary in which we express our craft or trade (and I’m ambivalent about the difference between craft and trade). Focusing exclusively on programming is like learning how to write excellent essays, poetry and email, when 70% of our communication is non-verbal. However, within that limited sphere, I do care about being fluent in our vocabulary, and I think that the people involved in the SC movement and I pursue many of the same goals. I would be surprised if any of us pursued those goals exclusively.

This post is more about the Software Craftsmanship manifesto, whose existence discomforts me.

I dislike the wording of the manifesto’s points because I don’t think they differentiate between programmers who genuinely care about the value they deliver, programmers who care about the beauty of their code, and programmers who hold a mistaken belief in their own abilities. Any software developer – even the naive, straight-out-of-college engineer with no knowledge of design and little knowledge of incremental delivery – could sign up to that manifesto in the mistaken belief that they were doing the things it espouses. I used to be one such developer, so I speak from experience.

I dislike the statement, “That is, in pursuit of the items on the left we have found the items on the right to be indispensable.” Indispensible? Absolutely necessary and requisite? Plenty of valuable code has been delivered by individuals trying out a new idea on their own; by coders like my dad who can’t make a maintainable product to save their lives, but who can rewrite it if they need to; by parties who started out on a basis of distrust and only learnt collaboration later on, let alone partnership; by people who couldn’t find the software they needed so wrote it themselves, or discovered unintentional value and responded to the change. If that phrase read, “That is, the items on the left are a good start and we would like to help you pursue the items on the right too,” it would be a less elitist message. For those developers who would like to be better, and who are aware that they’re learning, the manifesto casts them into the role of the “others” which Software Craftsmen are “helping to learn” the craft. I guess I’m one of those “others”, because I’m still learning about the items on the right, and I certainly can’t see myself as one of the craftsmen with the manifesto phrased in the form it currently takes.

Ade has outlined a number of mistakes which proponents – and I believe opponents – make regarding the software craftsmanship movement. I think supporters of the manifesto are doing exactly the same thing; failing to look at the background of the movement, and jumping on a bandwagon which lets them concentrate on the things they find stimulating while ignoring the bigger picture. “The glamour is overtaking the intent”, as Dan North put it. If Dan’s post does nothing but address the glamour and steer developers away from indulgence in the technical intricacies of their work – refactoring to oblivion while failing to deliver, focusing on test coverage while the company continues to leak money, worrying about the latest testing tool while failing to talk to stakeholders, or insisting that no one can interrupt their two-week sprint once they’ve made a commitment, for instance – then I applaud it.

I particularly liked the conversation between Dan, Aviv Ben-Yosef and Jason Gormand over Twitter, in which they concluded that Software Craftsman is a status you should be awarded by someone else. If nothing else, Dan’s post has let us have a conversation about what craftsmanship really means; a conversation which should be at least as public as the manifesto itself.

Ade, a further reading section attached to the manifesto is an excellent idea. Without it, that manifesto is the face of the Software Craftsmanship movement. I don’t much care for the expression on that face.

Posted in life, values | 20 Comments

Agile Training – a Recipe for Failure

Posted on January 13, 2011 by Liz

Some while back, I was invited to a meeting with two people who worked within that area called “Human Resources”. To be fair to the individuals concerned, neither of them ever referred to people as “resources”, and indeed both of them showed an uncommon desire to learn about what really worked in companies and projects. However, the conversation started as many Agile conversations with HR often do.

“We understand that the IT department is transforming to Agile. What training courses would you recommend?”

Apparently this is the way that many methodologies and practices – including Waterfall, Prince 2, and most lately Scrum – have been taught. I’ve only found one company who managed to successfully transform to a Lean / Agile way of working from a few Scrum courses run by Martine Devos, and they did it because their culture was so well set up for it. No other company that I know of has made a transformation to Lean or Agile without significant external help. Dan North has previously compared companies who can’t deliver software, and are wary of external help, to patients too shy to tell the doctor about their constipation. It’s a shame that we can’t simply say, “Don’t worry; take two of these pills and eat some prunes.” Agile isn’t something which can be taught in a couple of days. Really.

Still, they can make a good start. I outlined the things that I found worthwhile in an Agile training course. I provided some hints and tips for making the learning from those courses stick and ensuring that development is ongoing. I also provided a caveat that I’ve come to regard as almost a tradition. If you ask me to teach the people in your company Lean or Agile, I’ll also give them some basic skills to spread that movement and develop their skills further. I’ve not yet seen Lean or Agile survive without some champions on the ground, and one coach can’t do enough on her own. Furthermore, the basic skills I teach to spread the movement are related to life coaching. I will be training staff with the ability to look objectively at their projects, chunk their observations up to their personal values, decide on their goals, and match their lives to their goals accordingly. It helps them to leverage their passion; to make people care as much about their work environments as they do about watching the footy with their mates, coming home to their loved ones, or tucking their babies in at night. When you’re giving up forty hours a week to a profession, the opportunity to develop passion around that profession is addictive, and rightly so.

Often the people I pick to help make the change are those who are most dissatisfied with the status quo, and who want the change to happen. Even if I don’t help these individuals to help themselves, they usually find ways anyway – a little bit slower, perhaps; but just the knowledge that change is possible, and valued, seems to cause them to go out and seek new ways of doing things. Having a coach on the ground and an explicit mandate for change accelerates their desire to do something different and their acquisition of practices that will show them how. They tend to value principles over practices; they don’t really care which Agile toolbox we use, but they do value self-empowerment, transparency, honesty, care for one’s work and pride in the result, delivering real value, getting feedback and learning while they do it. They’re often the quiet ones, working tirelessly behind the scenes to make sure that a project succeeds; or the loud ones, vocal in their objection to existing practices which don’t help them to deliver. They’re usually the ones you want to keep, too, especially if the Agile transformation is going to succeed.

If you happen to be the kind of company who allows its goals to conflict with those of its staff, Agile training could be quite dangerous. If you want training in Agile, you are going to have to support your staff in adopting it. The skills they obtain will be hugely valuable within the industry. There aren’t enough people with these skills to satisfy industry demand. I browsed a couple of UK job sites over the recession and the Agile role demand dipped for about 3 months, 6 at the most. I hear that skilled professionals in the US haven’t been out of a job for long, either. Whatever gratitude your staff feel at being given the training will be weighed against your support of their new, tantalising, fun way of working; an assertiveness or curiosity which perhaps weren’t there before; and a disinclination to play victim to project management decisions when a different way of thinking could see them in control of their lives.

In other words, if you train your staff in Agile, you’re also training them to see through some of the aspects of business which don’t always make sense. These might include bonuses, yearly reviews, corporate standards, unreasonable deadlines, blame cultures, overtime cultures, unnecessary projects, unnecessary features, unnecessary management, unwieldy timesheet systems, holiday restrictions, cost-cutting on tools, cost-cutting on infrastructure, cost-cutting on coffee (never do this), awkward seating arrangements, lack of meeting facilities, dodgy third-party software, alienated offshore teams, command-and-control management, unconfident management, bullying… the list goes on. Of course no company can change overnight – but the only way to retain staff newly trained in Agile is to listen to their concerns and act on them.

Agile isn’t a mechanism for success, whatever you hear in the brochures. It’s a mechanism for making failure transparent so that you can adapt quickly, and it will show failure at many different levels. For companies who are genuinely interested in improving their ability to see difficulties emerging so they can respond, Agile is a godsend; otherwise, it’s a curse.

You can minimise the effects of Agile transformation by starting small – taking one team, and slowly growing the adoption – and this will give you time to respond. You will need to respond, or you’ll be fighting a tide of people leaving, and a growing number of companies wanting to hire new staff with Agile skills and passion. If you want to be ahead of the wave, keep the staff you’ve got. Talk to them. Find out what they most want from their jobs, once they’ve got a better idea of what’s available. Act on it. The average developer appears to have a frustration threshold of a few months, six at most, with testers and analysts not far behind.

You could, of course, resist transformation. Retain the old command-and-control structures, the change requests, the three-month documentation cycles. It takes longer to respond to change, and in many domains, change is happening faster and faster. Eventually someone will start to take over your portion of the market, differentiating themselves and responding to industry changes faster than you can. If a company wants to stay in business when technology, society and markets move so quickly, it is inevitable that teams will need to be empowered to respond to change themselves. Any such empowerment will bring the same transparency and the same problems that I’ve outlined here, whatever banner it comes under.

Failure is inevitable. It’s already happening. Companies who accept it can handle failure and adapt. Lean and Agile practices will make it visible more quickly and provide some mechanisms for turning it around. Traditional practices will keep it hidden until later. All you can do is prepare for failure and the problems that it will bring. Engage all the departments, including Human Resources. Be ready to change your metrics. Be ready to listen and get feedback.

Be ready to fail… because failing, and preparing for failure, is the only way to succeed.

Posted in coaching | 7 Comments

Giving effective feedback: How to change your Code’s behaviour

Posted on December 2, 2010 by Liz

Have you ever wanted to change the behaviour of some code that you work with?

I’d like to share a few techniques with you which have helped me to change the behaviour of code I’ve worked with, with little conflict, great success and positivity all round.

Imagine a legacy system who’s been in the job for five years and can’t see the problem with the way he’s behaving.

Imagine a class, who feels like he needs to be in control of everything, and can’t delegate or trust other classes effectively.

Imagine a service who’s overloaded, doing the job of three systems that no longer perform, but who just heroically accepts all the work and never gives any signal that he’s about to collapse, again.

We’ve successfully used these techniques to help change our codebases, our systems, our services and our applications, as well as our people. I’d like to share these simple guidelines with you, based on the sandwich model of feedback. They are:

  • Start with the right mindset
  • Anchor the things you value
  • Avoid labelling
  • Use examples
  • Work towards a bright future

Start with the right mindset

There are lots of reasons we might want to change our code. I’ve seen people work on code

  • because it doesn’t work the way they expect
  • because it’s annoying
  • because it refuses to do something which isn’t really its responsibility anyway
  • because it’s fun and powerful to change code for the sake of it.

I believe there are only two good reasons to change code:

  • to reinforce valuable behaviour
  • to increase effectiveness.

If you’re not approaching the code with one of these mindsets, stop. How much do you actually respect the code you’re about to change? All code wants to do a job effectively. No code is perfect. Remember that time when you first wrote code? You were learning, too. If you can approach the code with an appreciation for the things it does right, and build on those, you’re more likely to meet with success.

As an example, I had one piece of code which controlled the registration of pets. I really wanted this controller to broadcast a pet’s registration, but instead of communicating asynchronously, the controller was insisting that anyone who requested the registration of a pet hung around, waiting.

Unfortunately, one of the people who requested pets was the GUI – an extremely important class with a lot of other jobs to do too!

The code was frustrating me so much that I almost got rid of him and replaced him with someone else… but then I thought about it, and remembered that apart from the fractious relationship with the GUI, the controller had been doing his job very well. This respect allowed me to change the code’s behaviour instead of replacing him.

Anchor the things you value

Once you have an appreciation of the value of the code, make sure that the code knows. Reinforce this. You can call out specific examples of times when the code has done something well.

I told my controller, “I appreciate the way in which you register pets, and the effective way you delegate to the repository. Here’s an example. I registered a new rabbit, Snowy. I gave you his date of birth, his breeder and the price I wanted to sell him for, and when I verified it with the repository later, I found that you’d passed the information on very well. This is important to me.”

I tend to use a unit testing framework and perhaps a mocking framework – Moq or mockito – to translate these conversations into the language of the code.

If it’s a whole team whose behaviour needs to change – perhaps an entire application – then I’ll get everyone together and talk about the things that the entire team does well. For this, I use scenarios, either with a DSL or perhaps a BDD tool like Cucumber or JBehave. Automation tools like Selenium or WiPFlash let me translate my feedback into something they understand.

By anchoring the things that I value about the code, I can change his behaviour without fear that he’ll change in ways I didn’t want.

Avoid labelling

There are two types of labelling that I avoid: negative labelling, and pattern labelling.

Once I was judging a competition in which a coder announced, “This code is shite!” I marked him down. “If any other coder hears you say that,” I said, “they’ll either be wary of trying things out or they’ll think it’s OK to start devaluing other people’s code.” Labelling code negatively this way can be damaging for everyone involved in the project, even if you wrote the code.

Labelling code by calling out the patterns of behaviour can also be unhelpful. I remember one piece of code that got labelled as a “Visitor”. From then on, everyone expected it to behave like a Visitor. No matter what its responsibilities were, coders expected it to behave like a Visitor and encouraged the other classes in the system to do the same. Eventually the code broke down so badly that we had to replace it altogether, just because we had labelled it badly.

Use examples

We already looked at how to use examples to anchor positive behaviour instead. We can also use examples to show the difference between the behaviour we want, and the behaviour we’ve actually got.

“Instead of watching the repository,” I told the controller, “I’d like you to listen to him instead, and trust him more. Sometimes the repository might give you a message. I’d like you to respond to that message.”

“How long do you want me to wait after saving to get the message?” the controller asked.

“Don’t wait,” I told him. “Instead of telling me it’s done, I’d like you to tell me that it’s in progress instead. Let’s say that the repository takes five seconds. You should be responding in less than one.” We used some threading to illustrate how the repository might go off and do its job, and talked through the example in the controller’s language until I knew he understood.

Work towards a bright future

By focusing on the positive goals we want to achieve, we don’t really have to spend much time on the negative aspects of the code’s behaviour. After the examples were written, the controller was able to verify that his behaviour had changed appropriately, with as little fuss as possible. What’s more, he had those tests available to him going forward, so his behaviour stayed fixed. Eventually he became one of the most important classes in the system, responsible for the interactions of ten other imports – but he never got overwhelmed by the job.

We can do the same thing with scenarios and applications, or performance tests and whole systems. The ability to define the behaviour we want is one of the most important aspects of changing the behaviour which exists.

Posted in bdd, humour, testing | Leave a comment

CodeRetreat

Posted on August 17, 2010 by Liz

I always have so much fun at Agile 20XX conferences that it sometimes feels anticlimactic when they end. This year, however, I was lucky enough to get one of the last few tickets for Corey Haines’ latest CodeRetreat in Orlando.

The CodeRetreats are focused on having fun while learning, and follow a simple formula: 45 minute sessions of pair-programming on Conway’s Game of Life, then deleting all the code written and taking a 15 minute break. As well as giving up his time, Corey organises a storming lunch. Thank you Corey!

Deleting the code, for me, is the magic. I didn’t fully understand until Corey tutored me out of my outside-in, BDD habit at the last Code Retreat in Bletchley Park. “Why did you start with the Grid?” he asked.

“Well… because that’s how I’ll know I’ve solved the problem.”

“Are you trying to get things done?” Corey asked. “Don’t try and get anything done. 45 minutes isn’t long enough, and we’re going to delete the code anyway. Why not pick something interesting and see if you can find a different way to do it? Why not look at the rules, or a single cell, or the number of neighbours?”

I got it. CodeRetreat isn’t about solving a problem or getting something done. It’s explicitly the opposite. It’s about learning, even if that means you never solve anything or get anything done. The 45 minute period is just long enough to learn significantly but not quite long enough to make any real headway, unless you already know the Game of Life backwards.

As part of teaching BDD and driving out various BDD tools, I’ve produced multiple implementations of the Game of Life in Java and C#, to the extent where I already have a good idea of the classes I’m going to use. That can actually be a handicap in the CodeRetreat, because it makes it hard to learn anything new. I often find myself letting my pair take the direction, just to see if any other interesting patterns emerge.

In Orlando, we were lucky enough to have several great programmers amongst us – including Michael Feathers, Brian Marick and Uncle Bob. Having already experienced a cage match between Michael’s Haskell and Brian’s Clojure implementations of the Game of Life, I was excited by the opportunities to learn a new language. Brian was kind enough to show me some of the language features in Clojure. We didn’t really get very far with the problem, but that’s OK – the object was not to solve the problem, just to learn. Thank you Brian!

For the last session of the day, we voted to use a bit of extra time to conduct a longer session, and Bob kindly volunteered to help me continue exploring Clojure. We started with a function which would find all the potential candidates for life in the next generation, and worked from there.

10 minutes before the end of the session, we had a working copy, which Uncle Bob has kindly blogged here. The code is a little tidier and a lot more readable than the version we ended up with. I need to find out what conj and % do! We should also have deleted it, but since we had already gotten something done, it was too late.

Clojure turns out to be a very beautiful language, and Uncle Bob is a lot less scary in real life wonderfully patient mentor. Thank you, Bob!

Posted in conference, learning | Leave a comment

The Gordon Pask Award

Posted on August 13, 2010 by Liz

The Pask Committee have given the Gordon Pask award to me this year for deepening existing ideas and coming up with some pretty crazy ones of my own.

I can only do this because of the fortune I have in my communities, including some great coaches on either side of the pond, the Extreme Tuesday Club, Thoughtworkers and alumni, and the wonderful online communities in Lean and BDD.

My communities give me a safe place in which to play and get feedback. I am a member of a community of thinkers, and if I should happen to be a catalyst more than others, I consider that to be a tribute to those who have inspired me. This is as much a measure of your success as of mine. Thank you all.

Posted in coaching, conference, life | 4 Comments

My Grandad

Posted on August 7, 2010 by Liz

My Grandad looked like Merlin. He had white hair down to his shoulders, steel-blue eyes that sparkled when he grinned, and half his teeth.

My Grandad worked as an engineer during the war. He used to talk about the bombers, who always claimed they were able to hit a target, even though my Grandad pointed out that the practice “bombs” they were dropping hadn’t actually fallen into the nets he’d put in the targets. It was, he said, the only way to test whether they were telling the truth. He was a keen physicist, mathematician and astronomer, and had a marvellous fascination with history and pretty nurses.

In the last few years his memory, and his body, started to fade. He stopped being able to hold on to conversations, but still enjoyed doing the crossword. He read books and papers. He loved to drink whisky and eat sweets. The last time I saw him, we brought him some jellied fruit. “No thanks, Grandad,” I said. “You have them.”

“Oh, good,” he grinned, and hid the box. I never saw a smile on his face that wasn’t a grin – cheeky, half-mocking, and often poking gentle fun at my ever-patient mother. That’s how I’ll remember him; by that smile, and the sparkle in his eyes.

My Grandad passed away in his sleep last night. He would have been 98 next month.

Sleep well, Grandad. I love you. Thank you for making my world a better place.

Posted in life | Comments Off on My Grandad

What not to test

Posted on July 23, 2010 by Liz

A couple of people have recently written asking for advice on how to start writing scenarios. In both instances, they have started by logging in, because “that’s what the users do first”.

If you’re doing BDD, may I suggest starting not with the scenario that describes the entire user journey, but instead, the scenario that describes the riskiest bits of the journey?

Assume that whichever user has access to the system is already logged in. Logging in isn’t exactly risky. It’s been done 15,000 times before.

Hard-code the data to start with. Getting data out of a database isn’t very risky either. You can code this later without affecting the scenarios, if you can get some realistic examples of data.

Work out which bits of the system you know least about. Create the scenarios and have conversations around those bits of the system. You don’t have to grow the system from the beginning – you can pick any point you like! Which bits of the system make you most uncomfortable? Which bits make your stakeholders most uncomfortable?

Those are probably the bits which will cause your project to succeed or fail. Logging in can come later, and by the time you come to code it, you’ll have some real value that people want to log in for.

Posted in bdd, testing | 5 Comments

The Haiku Workshop at SPA2010

Posted on May 2, 2010 by Liz

I’ll be running the ever-popular Haiku Workshop in the SPA2010 evening diversions on Monday 17th May. My focus for this is limited to 24 people. I’m not sure how attendance is being organised; however, if you want to attend and find out before I do, get in there quickly!

Posted in coaching, conference | Leave a comment

WiPFlash and IronRuby

Posted on March 19, 2010 by Liz

Ben Hall has blogged his use of WiPFlash together with IronRuby to test Windows applications. Thank you, Ben!

The example UI that Ben’s using is WiPFlash’s own. I particularly wanted to provide a pseudo-realistic application, so WiPFlash has a pet shop. It works in memory, with hard-coded data – the idea is just to provide a realistic UI. This has really helped me to learn more about WPF and Prism, and get useful feedback about what I’m doing wrong from people who know better!

A pet shop

I have a couple of additional features I want to add before we move to 0.X releases, then I’ll stabilise the interface and make sure it’s all configurable for 1.0 – so if there’s something missing which you’d need to use WiPFlash on your project, please let me know. I’m trying to keep this really light-weight, so I might say “no”, but I promise to make you feel good for asking!

Posted in csharp | Leave a comment