Common wisdom, and self help books, says that anyone who completes 10,000 hours (10 years) in their chosen discipline will excel. This is part of the rationale for Code Kata and Coding Dojos from the Software Craftsmanship movement. But the 10 years equals expert formula isn’t true.
Continue reading
Tag Archives: technical practices
Who is Specification by Example for? Everybody!
I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
Continue reading
Solution Convergence: Marrying Business, User Experience and Technical Input
My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”.
Continue reading
My four days of silence surrounded by developers
Developers are different from other folk. Introverted is an understatement. My four days of silence really highlighted this.
Continue reading
PMs Need a Technical Ally When Introducing Automated Testing
I need a technical ally when introducing Specification by Example and BDD. Actually I need a technical ally when introducing automated testing of any kind. Somebody to coach / mentor / encourage / explain / enthuse about the technology and how it helps.
Continue reading
DRY Gherkin: When Using Cucumber, Keep Your Step Definitions DRY
When using Cucumber for automated testing I try to ensure my Gherkin uses ubiquitous language so the business and development team share a common language. But the Gherkin must also be DRY. This not only saves confusion but also saves development effort.
Continue reading
Improve Customer Collaboration with Ubiquitous language
Normally I’m quite a calm chap but I get quite grumpy when developers want to model the business domain using technical language. I believe in using “ubiquitous language” and that means using business language to model the business domain.
Continue reading
Brakes let you go faster
Perhaps counter intuitively brakes let you drive fast. Without the brakes we would drive really, really slowly. I believe the same is true of automated tests. Something that looks like it should make you go slower actually lets you deliver code faster. As long as you’re doing the right tests.
Continue reading
Declarative vs Imperative Gherkin Scenarios for Cucumber
Everybody I’ve met that is new to Gherkin starts with an Imperative style of scenarios. The Imperative approach is simple and intuitive and reflects what manual testers do. But I hate the Imperative style with a passion. I favour a Declarative style of scenarios not least because a declarative style means I can test business rules. The UI is prone to change but the business rules tend to be more stable.
Continue reading
Developers don’t have time for code reviews and unit tests
The ticket moves to “Dev Done” but there are no unit tests and the code hasn’t been reviewed. When challenged the developer says “That’s because I don’t have time for that stuff”. If I hear that I want to know why they feel they don’t have time, then I give them the time.
Continue reading