When not to use BBD (yet)

What is BDD

This blog is not about explaining BDD in detail, but here’s a short description. BDD is a way to build software against tests that are defined beforehand. BDD allows you to make sure your whole application is working, not just parts of it. It’s basically an outside-in way of testing, as apposed to unit testing which is focussed on the inner parts of the application.

What BDD is not

BDD is not a way to discover your application’s requirements or use cases. It’s a way of documenting the requirements and use cases in an executable way. Even the Wikipedia article on BDD gets it wrong here, so it’s a common misconception.

The pitfall I’ve come across is always starting your user story implementation with BDD. In the cases where you know how your application should behave that’s fine, but when the behavior still needs to be fleshed out BDD can get in your way. The confusion is between problem description and solution design, BDD is solution design while you might confuse it for problem description.

So let’s take an example:

Suppose your customer wants to have a view on the customers orders. The orders are stored in a database, but not necessarily¬†in a user friendly structure. The user also isn’t very familiar with all the data that is stored in the order, because some of the data comes from external systems. Now, when you start asking your user for BDD examples, you will probable fail. You can’t get examples for statuses, missing information, multi-line orders etc. because the user simply doesn’t know what he/she wants exactly at this stage.

So the usual course of action is to either discuss some examples of the data, but in this example the we ‘just build something ™’. We asked the users to interact with the data for a few weeks by just showing the raw data structure. The users could relate the stored orders to other sources of information, their work process and past systems that stored customer orders. Only after that experience could they tell us how they wanted to see the data, what features they would like, what manual steps they’d like automated. And only now could we actually create a BDD scenario.

If you’d started with BDD, you would have been describing user goals and scenario’s that they couldn’t really support. Since you’re not building to solve their problems (because you don’t know them yet) how can you create BDD scenario’s? In that case your BDD tests will just be system integration tests, not value driven scenarios. So skip BDD in this case until you’ve learned a little bit more.

Lean Startup Approach – paper mockups

In the Lean Startup reminded us all of finding out what problem you’re solving before you start solving it. The goal in the Lean Startup is learning about your customers problems, desires, needs etc. The trick is to find the fastest (and cheapest) way to learn so that you can solve the right problem effectively. Sometimes writing code is the easiest way to start learning, get something out there. Now this kind of code is similar to the post-it notes in a customer brainstorming session: you throw them away.

Wrapping up

So to summarize, if you know how the application should behave use BDD. Often when a user just wants the same features he/she has seen before on another application or website, the behavior is clear. If application behavior is not clear, make sure the problems/needs are discovered and you’ve agreed on the application design before starting BDD.

A drawing that explain the two scenarios:

Application behavior is known, use BDD
Discovering through building, use BDD later
Advertisements
When not to use BBD (yet)

The State of Agile Estimation

The problem with estimating

Estimation is one of the holy grails of software development. Imagine if you could tell your customer exactly when something is done and how much it will cost…no more deadlines, no more surprises. That would be something, right?

But the world is not perfect, it’s complex. So estimation is hard. And when you work on something risky and challenging, which is hard to estimate, your customer probably wants to have accurate estimates even more!

Agile estimation has been around for a long time, XP and Scrum have brought us story points, velocity and (with the help of some project managers) project burn-downs.

Two years ago, my team was doing Scrum estimation by the book (I still don’t know which one though). The backlog was estimated for months ahead estimation and velocity was tracked as if our life depended on it. As in many teams, this didn’t work quite the way it was advertised. Planning meetings were tough, estimates (in points) often way off, pressure was mounting and code was rushed at the end of the sprints to reach the velocity the team committed to. No, if you have any experience in Agile, you’ll probably find a few mistakes in there.

So we want estimates, but they are hard to get right. We’ve had some interesting experience with estimation ourselves.

Stop estimating

We decided to stop estimating. First we needed to get the quality right, the process stable and the testing to be synchronized with coding. So we decided to reduce estimation to a bare minimum. Since we started we went through the following levels of estimation:

  1. Full fledge Scrum Estimation and Tracking ™
  2. No estimation, just keep working until the MMF was done (an MMF is something the user can see, touch, taste or smell)
  3. Estimate the size of the MMF
  4. Try to keep the MMF size within 2 weeks

We’ve been stuck at 4 for quite a while, using a continuous development process. MMFs are not always the same size though, some can’t be reduced to two weeks and others are just not estimated correctly. There are two reasons I want to get back to a higher level of estimation and tracking:

  1. Visualize what the team achieves in a given period, much like we track our product performance in the field; you want to know if you’re improving.
  2. Give the stakeholders some idea when to expect which MMF in the coming months.

These two goals are different, the target is different, one is the team, the other is the stakeholders. I’m hoping to find a minimum viable tracking system that can serve both goals.

Wanting to track the work done and have some (rough) prediction of what we will deliver in the coming months is our goal. Let’s see how to achieve that.

The state of estimation

So, to get back at (team) estimation after disbanding it for 3 years should be interesting. A quick search shows me a mixed bag of the current state of Agile estimation. Three years ago, estimation was non optional. Everyone was doing Scrum (or waterfall) and estimates and velocity were the best things since sliced bread. Today, the situation has changed, with probably many people sharing the same experience we had (estimation sucks). So there seems to be two main approaches to estimation these days:

  1. Use very little estimating and focus on fast delivery
  2. Do estimation all the time

Examples for the first (little estimation) often stem from the Kanban arena. Some suggest just counting bite size stories. The stories are roughly the same size, so you can just count how many you’re doing each time period. Predicting far ahead into the future is not possible (and not a goal).

Scrum.org has removed velocity and story points from the guide, but the act of estimation is mentioned and still a key attribute of Scrum. How you estimate, it doesn’t say.¬†Joel Semeniuk gives a good overview of how to tackle estimation.

Try, inspect, improve, repeat

We’ll give estimates another go. The mean principles I think should apply:

  • Estimate on a high level
  • Separate size estimation from measuring time spent
  • Track predication accuracy

Expect another blog post as we learn more about reintroducing estimating. If only I could tell you when I will write it ūüėČ

 

The State of Agile Estimation

Version numbers are overrated – use version labels instead

Most developers use version numbers for their software. It’s considered a ‘best practice’, but version numbers are overused and give you a false sense of control and compatibility. Use the simplest versioning scheme possible, where versionless is the simplest.

Rationale

What is a version number? It’s a label (doesn’t have to be numeric) that identifies one particular snapshot of your software. Usually there is one overall version number for the whole system, even when components of that system have their own versions. Using this label, anyone can reason about the state of the code for that label. Users might say, in version IE 9.0.1.2 there is a bug when I try to print. The developers will know exactly which state the code was in for that version number and should be able to find and run that version (and fix the bug). Summary: you need to label revisions of your code to refer to it later.

Numbers are silly

So far, so good. Version labels are useful. But in stead of labeling the software with a date of release, the name of the latest feature, most developers use numeric labels. And not just a sequence number (1, 2, 3), but fancy numbers with dots! Giving your application a version number like 15.0.12.21.h makes it (and you) look really complicated and smart, don’t you think? Have you seen the Chrome version numbers? Anyway, let’s go into these version numbers more deeply.¬†A typical application, let’s say a website for creating blogs, releases these versions:

  • 1.0
  • 1.1
  • 1.2
  • 2.0

What does that mean? Well, convention says:

  • first ever release
  • small change
  • small change
  • big change

That’s it, nothing more to it. But the numbers look more professional, don’t you think? Although list 1 and 2 have the exact same meaning. And was the change from 1.2 to 2.0 was really that big? We don’t know. What this developer deems big, might not be so big and worthy of a ‘major’ version bump for others. So why use numbers at all? Why not use descriptive names like:

  • ‘first basic YourBlog release’
  • ‘fixed bugs in login’
  • ‘fixed bugs in page-saving’
  • ‘redesigned UI’
Now you might argue that you can’t see which version preceded which. Who cares? If you need get back to the exact version of fixed bugs in page-saving¬†you can just check out that version (assuming you’ve labeled it in your source control). If you want, you can track the chronology somewhere else. Or you could add the date to the label to signify when it was released to add even more meaning to the label:
  • ‘2011-1-10 first basic CMS release’,
  • ‘2011-2-1 fixed bugs in login’,
  • ‘2011-2-9 fixed bugs in page-saving’,
  • ‘2011-3-2 redesigned UI (big change)’.
Now you have everything you need, suppose you read theses labels in your source control? Much better than just 1.1, 1.2, don’t you think?

My Application is an API

There are cases where using the dot-numbers make sense: when you’re developing an API or library for public use. Then the numbers signify something very important:¬†compatibility. The convention basically says: if you increase the number behind the dot (1.1 -> 1.2), the library will be backwards compatible with all 1.x releases. When increasing the main (major) number (1.2 -> 2.0), compatibility is not guaranteed with 1.x releases. That is quite an exact definition of a big change. So if your API is always backwards compatible, you can stick to 1.x releases forever.
Now, this might be the root cause of the wide spread use of numbers as version labels. Most developers think API development is the coolest thing in the business and many practices (like misuse of interfaces in Java) stem from thinking your code will be used as an API. In reality, most code is not an API. GUI applications don’t have a programatic interface, so they don’t need version numbers. Even if you’re releasing a new version of your library for in-house use, no one will trust your backwards¬†compatibly¬†claims anyway and just re-test their whole system using your new version. Only when the library is developed externally, you want to know if you can upgrade safely or not.
To summarize: for API development version numbers signify something important, most people don’t build public APIs but build applications or websites that don’t require this strict convention.

Maven: WTF?

Maven doesn’t help in making people¬†steer¬†clear of the number fetish. When you create a new maven project. The initial version for you module is: 0.0.1. Yes, not one dot, but two! You’re going to be doing some serious API-building business. No, you’re not.

What does that mean? By convention, 0.0.1 means ultra-pre-beta-alpha release. It’s probably just prints ‘hello world’ in a console. So you start building and maven increases your version with every release you make. 0.0.1, 0.0.2, 0.0.3. You’re not making much progress, so after a few weeks you make the bold move and change it to 0.1, your first pre-beta-alpha release! Or is it, perhaps it’s already live, in production and making money. When do you switch over to 1.0? When all the bugs have been fixed? The first time you go live? 1.0 means done, right? Stable, right? Yes, it does. But your website is never done, your GUI will always have issues so there is no 1.0!

I find when building whole systems, there is never a clean cut release. The first public release is not much different from the one before or after. So stop fiddling with the numbers.

Just to get back at the API argument, when you release an API to the world, there will be a 1.0. It’s that contract again, meaning: this API is stable and ready for production use, it has¬†undergone¬†testing and everything. This number means something because your communicating it explicitly, it’s in the product you ship (like commons-lang-1.0.jar). Your website just has a url, your GUI an icon, no version.

Version-less coding

Some code doesn’t need version numbers at all, it’s just code. If it’s checked into source control (on a particular branch) it’s usable. No 0.1 release or 0.1-SNAPSHOT. Just the code. If I want to make change that breaks stuff, I’ll create a separate branch. Maven doesn’t allow this, it’s basically duplicating what my source control system can do better (track revisions). For libraries, I might want this, but for my main project, I don’t. One of the reasons these version numbers are still so prevalent, is that Maven requires a version number. Starting with 0.0.1 will start you off thinking you need a complex version numbering scheme.

The build number alternative

I propose a complete alternative to using version numbers. It’s simple: build numbers and labels. Every time you build your system, for instance in your CI tool (like Hudson) it gets a build¬†identifier, let’s say a timestamp. That number might be set in your source control as a label or the revision of the code might be stored alongside the build number, either way the build number will be a reference to a specific state of your code, but also a specific attempt to build that code. Sometimes you have to build the same code multiple times to get a good release (your build procedure might have issues). Now the build numbers are just a sequence. You can label releases that are actually going out for release, so you can refer to them later. Using the build number, you can even pick up the exact artifacts from that build.

  • 2011-01-01-1543 – ‘added new content type’
  • 2011-01-02-1218
  • 2011-01-02-1543
  • 2011-01-02-1743¬†– ‘improved render time’
  • 2011-01-03-1109

Most CI tools (like Bamboo, probably others too) even support labeling a build.

One extra benefit of this, is that your code doesn’t have to contain version numbers. I think it’s a smell that the version of the code, is in the code. The version is something external to your code, your source control system has to deal with revisions, not the code itself. You’ll see that a lot of web projects don’t have a version at all, it’s just the code.

So, using labels in stead of dot-numbers, everyone will know what the version entails but you don’t have to worry about the numbers anymore. So, let’s make it easier!

Version numbers are overrated – use version labels instead

The Task Board Retrospective


When did you last improve your task board?

Most teams working with an Agile process like Scrum use a task board (physical or digital). Even many teams that only do a bit of Agile or Scrum will work with a task board. It’s a core practice in Agile software development, not specific to any methodology. So, it’s common practice.

So like all things in Agile it should be subject to scrutiny once in a while. A fair question is, why have a task board at all? Just because you’re doing Agile(tm)? No one benefits from blind adoption, so ask yourself this question. Not to get rid of your task board, but to find out if it really fits your purpose and to find room for improvement.

Continue reading “The Task Board Retrospective”

The Task Board Retrospective

McLuhan, the iPad is the message

Marshal McLuhan‘s work is one of the cornerstones of ‘media theory’. His view on media as an extension of ourself and the effect they have on our society are profound. I was introduced to McLuhan by Mark Federman at Agile2008. Although it would take years of study to fathom the depth of McLuhans insights, one convenient tool to get more insight into any (new) medium is the quadrant with four questions. These questions help you understand the true meaning and effect of a medium. The focus here is on the medium itself, not the content, that’s why McLuhan is often quoted saying ‘the medium is the message’. The medium can have a far greater impact on society than the content, television being a good example of this.

When exploring a new medium, four interesting questions to ask are:

– What does it improve or enhance?
– What does it neglect, displace or make obsolete?
– What does it bring back from the past that has been neglected recently?
– What does it overturn? (When pushed to its extremes, a technology fosters side effects that are opposite to the effects that were first expected, both positive and negative).

Now you could ask yourself these questions regarding the iPad, which is a new medium for conveying information and is quite visible an extension of its user. Using it as a knowledge base, navigating, helping us communicate with others it extends our natural abilities.

Back to the questions, let’s give them a try, perhaps your answers would be different, that would be a great start of a discussion of what the iPad actually means. Think sociological effects, not just purely functional. What helps is to image everyone having an iPad and/or using it for everything, what would be different in such a world? Answers can be both positive and negative.

What does the iPad improve or enhance?

  • It increases the time spent behind a computer (in the park, in bed, on the train etc.)
  • It enhances people’s ability to interact with data and software, it helps computerize society

What does the iPad make obsolete?

  • Some people thought it would make the laptop or¬†net-book¬†obsolete. I’m not too sure about that, but you might say it makes the laptop less¬†favorable¬†for watching movies or pictures. But that’s is not a sociological effect in itself.
  • Books, encyclopedias, cook books, news papers.
  • It makes staying at home or at a desk obsolete (when consuming data)

What does the iPad bring back from the past?

  • The touch interface obviously brings back the tactile experience which other computers don’t have. Before the age of computers, dealing with information and entertainment was much more tactile, we had books and magazines and games were physical as well (board games). The iPad brings back interaction using our touch senses.
  • It brings back the book, but improved. Perhaps reading and engaging in stories will get an impulse.

What does the iPad overturn?

  • You could imagine that if everyone stopped using PCs and laptops and only iPads, users would consume only bite-sized data and though the iPad is an information-sharing device, if it’s the only thing you use, you might stop producing data. In effect limiting the information sharing.
  • Can’t think of more, this one is hard… ūüôā

Hopefully this has raised your interest in McLuhan and made you think a bit more about what sociological effects a new medium (like the iPad) has, often they have a far more profound impact on our society and way of thinking than we initially presume.

McLuhan, the iPad is the message

Front End Architecture

HTML/Java Workflow & Architecture

Currently I’m thinking about different ways to set up a good set up for creating/changing websites. When your team consists of HTML/CSS developers on one side that know about user interaction, graphics and layouts and Java developers on the other side that excel at making data available and dealing with the complexities of 3rd party communications. The¬†challenge¬†is to set up the team and architecture for an effective workflow, letting everyone do what he/she does best.

The context is a company that has a lot of data and wants to make this data accessible through multiple channels and sites. The user experience is a very important, so tuning the websites on the HTML level is an ongoing activity. Expanding to new devices and websites is one of the (technical) objectives.

The way to set up the components and what abstractions to use is not obvious. After speaking to some peers in the industry, I’ve distilled three main options to choose from. Combinations are possible, but I’ll describe the simple case. I haven’t decided which is best, though and I might be overlooking some crucial things. My main goals for any solutions are:

  • Zero round-trip while developing HTML/CSS/JS
  • Independence of HTML developer when creating new ways to display the same data
  • Smooth work-flow from concept to implementation.

JavaScript All the Way

With this approach JavaScript takes care of all interactions of the website. A good example is the Google Start page, which contains very little HTML, but once you enter a search term, the content completely changes, using JavaScript

The pre-rendered HTML is very minimal, providing the structure that you fill with JavaScript. The biggest advantage is, provided you can create a clean remote API for JavaScript to access, total independence of your HTML development. As long as you want to display the same data, new websites can be created with few changes required on the back-end. Since the HTML doesn’t have to be server generated, it can be plain HTML all the way. Although that simplifies things there are some downsides as well. Google being the biggest issue; the content generated by JavaScript is not parsed by Google, so your site will not do well in the search engines. Getting the data to your JavaScript means you’ll have to provide an easy http accessible API (using JSON or REST etc.), it might not be trivial to come up with a clean API, basically you’re adding a¬†physical¬†layer to your architecture.

Pros

  • Largely¬†independent from back-end
  • Zero roundtrip when changing HTML
  • There is only one version of the HTML (no conversion to templates)

Cons

  • Google cannot index content generated by JavaScript
  • Complex workflows that keep state are harder to maintain/debug in JavaScript
  • An extra layer of
  • Performance and security
  • Re-use is limited

Server Side Scripting

Here you don’t let JavaScript fill your combo-boxes, but it’s a dynamic language like PHP/Python/Ruby/ASP that renders them (let’s assume PHP). The HTML is generated by a language that intrinsically supports a fast (save&refresh)¬†development cycle. Although these scripting languages are powerfull enough to build your entire application, you risk not¬†separating¬†the data from the presentation or trying to build things that are too complex (PHP-hell). So you will probably have your PHP access some (remote) API that handles the complex things. There is a bit more flexibility in terms of connecting your PHP to the back-end API and because the PHP is run on the server security is less of an issue.

Pros

  • HTML can be indexed by Google.
  • Short roundtrip when changing PHP
  • PHP code runs on a trusted server
  • Simple enough for HTML developers

Cons

  • Risk of PHP layer to grow too big
  • Extra runtime environment needed (Apache)
  • HTML only works after PHP parsing

The Java World

This is (for me) the most common model. Some Java Web-framework handles the user request, invokes a controller and passes the result to some HTML-template engine which renders the Java objects into HTML. The real difference here is that you have direct access to Java objects from the HTML template, so when you can model and access your data in Java, you can use these objects directly in your HTML. For Java developers this is very natural. Your web application generates HTML, whilst the developer can work and reason about Java objects almost all the way, the HTML is considered the VIEW part of the framework. One issue with this, is when the HTML layer is doing more than just render the data. Integrating interactive¬†behavior¬†in your HTML is handled by some frameworks quite extensively but at the cost of¬†proprietary¬†abstractions of both JavaScript and the interactions between front and back end. Although this works, it seems to be mostly geared towards Java developers that don’t want to deal with real HTML and JavaScript. Good for Java developers, unnatural for HTML developers.

Pros

  • Data access and HTML generation in one machine/JVM, easy and fast
  • Short development time for Java-heavy applications

Cons

  • Extra channels and websites will need to be¬†modeled¬†in the server framework
  • Templates are not HTML, only work when run inside the Java framework
  • Longer development round-trip, but needs full Java set-up with war overlay

Wrapping up

So what’s the best? Of course it depends. Did I miss any pros or cons? What do you use to get maximum productivity from both your back-end and front-end developers.

References

Front End Architecture

Quality vs. Automated Software Testing

Inspection is not enough

Deming is world famous, especially in the Agile/Lean world. During his life Deming taught top management how to improve design (and thus service), product quality, testing and sales. His name is synonymous to quality improvement and his philosophies are still seen as visionary.

One of ¬†Deming’s principles is: “Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.” Sounds good, right? In stead of testing every last inch of your product, you increase it’s intrinsic quality which is more sustainable, has a direct benefit for the customer and eventually lowers cost.

Now how does that relate to software development? In software development we do quite a bit of inspection, not only by peer reviews but mostly by testing. We test documents, units of code, modules of code, systems, user interfaces, services etc. We test functionality, speed, error handling, ease of use, fit for purpose etc. etc. My interpretation of what Deming would say to us: focus less on creating more tests, focus more on product and process quality.

Continue reading “Quality vs. Automated Software Testing”

Quality vs. Automated Software Testing