Category Archives: Non-technical

Articles that can be understood without coding experience.

Pair programming with Sankalpa

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others.

When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa. In this session, we achieved something that we would be helpless to do alone.

The task Sankalpa and I was working on was to include information from a calendar in Confluence in a date picker in a web application. As we sat down, I was dreading the integration part. Integration is often dreadful. More than anything, I wanted to hide from the problem. But with Sankalpa sitting next to me, I didn’t feel that I could give up, so I suggested we took a look at our Confluence calendar to get started. Sankalpa was at the keyboard and he found a “calendar feed” where I hadn’t thought of looking for it.

Looking at the feed, I exclaimed “Oh, I know this – this is vcalendar”. A quick Google later and we had found a library for parsing vCalendar in JavaScript. We quickly finished the code to adapt it to our desired format and moved to the date picker.

I was at the keyboard and I had used a date picker library called jQuery datePicker before. We quickly integrated it and I proudly refreshed the page to show the calendar events in the view! But it turned out that all the functionality that depended on picking a date was now broken.

I started grumbling about how I was much more comfortable with jQuery than with AngularJs. Unfazed, Sankalpa mentioned that Manoj had gotten the date picker to work with AngularJs in an earlier project. “Hey, Manoj, where did we use this date picker?”

Having much more experience with AngularJs than me, Sankalpa integrated the code into our code base and everything was working.

All in all, I had expected this to take 2-3 times as much effort. If we had been alone, we would probably wouldn’t have the courage to start with the integration right away. If he had been alone, Sankalpa probably wouldn’t had known how to parse the vCal feed. If I had been alone, I probably would have searched the Internet for hours to find out how to make AngularJs play well with jQuery date picker.

Together, we did what neither of us could have done alone. (At least not anywhere close to this quick)

Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | 1 Comment

Using pair programming to combat project waste

  • Less Overproduction (of unused functions in interface between team members)
  • Less Waiting (for the only person who knows a particular area)
  • Less Motion (as everyone gets more skilled)
  • Fewer Defects (because two pair of eyes see better than one)
  • Less Over-processing (from duplicate responsibility)
  • Less Inventory (as team works on focused set of features and tasks)
  • Less Transportation (handoffs inside a story)
  • Less Underused talent (as everyone gets to share their skills)
Posted in English, Extreme Programming, Non-technical, Pair programming, Software Development | Leave a comment

Om å løse alt bortsett fra det egentlige problemet

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine.

Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser – gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss). Og det er bare starten. Hvor kommer denne impulsen fra?

Jeg har hørt to teorier om hvorfor Java-programmerere ender opp med en kompleks hverdag. Den ene skylder på sjefene, mens den andre skylder på programmererne. Jeg vil ta for meg begge og peke på en vei ut av jungelen.

Teori 1: Steak and strippers

Zed Shaw, mannen bak “The motherfucking manifesto for programming, motherfuckers” skylder på IT-sjefene. Han mener at selgerne fra teknologiske giganter tar med IT-sjefer ut på strippebuler og kjøper biffmiddager til dem. Og vips så kjøper IT-sjefen inn et ubrukelig verktøy som programmererne er tvunget til å bruke. (Zed påpeker at det vil være positivt med flere kvinnelige IT-sjefer, ettersom de i det minste ikke vil være like interessert i strippebulene)

Ref: Zed Shaw: Control and responsibility (http://zedshaw.com/essays/control_and_responsibility.html). Zed Shaw: Programming, motherfuckers (http://programming-motherfucker.com/). Zed Shaw: Video – Steak and Strippers (http://vimeo.com/2723800).

Argumentet er underholdende, men forklarer bare en del av problemet. Mange av verktøyene som står bak kompleksiteten i Java-prosjekter er åpen kildekode og selges typisk ikke av selgere med fete representasjonskontoer.

Teori 2: Blinkende lys

Jeg tror en viktigere teori er at programmerere er opptatt av fancy ting som blinker. Enkle ting som firmaet tjener penger på er kjedelige. Å sette seg ned og flytte data fra databasen og putte det i en webside er kjedelig for en programmerere. Å lære seg et nytt rammeverk som gjør den samme jobben på en fancy måte er spennende. Å fjerne teknologier og lage en enklere løsning er kjedelig. Å innføre et rammeverk som skal skru sammen teknologien er spennende.

Alle foretrekker å gjøre det de synes er spennende. Jeg vet det, for jeg har vært der selv.

Grunnleggende sett tror jeg at Java-programmere selv har skaffet seg de problemene de ofte klager over med komplekse teknologier.

Veien ut av villmarken

For meg var det viktigste skrittet ut av villmarken foredraget jeg hold på JavaZone for to år siden. I foredraget bygger jeg og Anders Karlsen en webapplikasjon i Java uten å bruke webrammeverk. (Innbild deg at du hører et ironisk gisp her)

Jeg har øvet meg på å løse de problemene jeg har i prosjekter med å bruke enklere teknologier. Slik vet jeg hva de komplekse løsningen gjør. Og så langt er det nesten ingen løsninger som ikke innfører mer problemer enn de fjerner. Det de gjør er at de flytter fokuset fra den oppgaven programmet egentlig skulle løse over til alle de teknologiske delene som man skal få til å fungere sammen.

Jeg tror ikke programmerere er bedre eller dårlige enn andre mennesker når det gjelder det. Men vi har alle en tendens til å bruke tiden vår til å finne spennende problemer å løse i stedet for å løse det vi egentlig skulle på en naiv og enkel måte. Min far sa det egentlig best: Du bør ikke bruke en kalkulator før du kan løse de samme regnestykkene på papir.

Posted in Java, Non-technical, Norsk, Software Development | 27 Comments

If you’re an architect, knowledge is your enemy

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team.

The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages. When they realize that there’s not sufficient time set aside in the project schedule for the developers to read all this information, the architect may present the material to developers who sit and nod their heads. But what did they really understand?

Instead of the read-listen-and-nod approach, I prefer an approach that I sometimes call “dragging the information throught the heads of the team and looking at what comes out in the other end.” I provide as little processed information as possible, but instead give the team a structured workshop to uncover and structure the information by asking me or business stakeholders. The outcomes of the workshop should be some tanglible results presented by the team. This result is always different from what I had in mind. Sometimes the difference shows a critical misunderstanding, which allows me to go more in depth in this area. Sometimes the difference represents a trivial misunderstanding or difference in opinion and the architect has the difficult task of accepting a small disgreement without distracting the team. Sometimes, the team has discovered something much smarter than the original idea of the architect.

I find it most useful to do workshops in small groups of three people per group. Each group should produce something that they can show to the whole team afterwards. Here are some examples of workshops that I run:

  • Divide in groups of three with the users/business and the developers represented in each group. Each group should discuss and fill in a template for the vision of the product being created: “For some user who performs some business function the name of system is a type of system which gives a capability related to the task. Unlike most interesting alternative our solution has an important advantage“. The groups get 10 minutes before a debrief with the whole team.
  • Each group then brainstorms a list of users, consumers and others affected by the system and write these on sticky notes. This should be about 20-30 roles. The whole team decides on a few interesting users and the groups then write down for some these: What characterizes the user, what tasks do they perform and what do they value?
  • Based on the list of tasks that stakeholders perform, we create a sketch of a usage flow. I like to refine the documented usage flow with a small task group which takes a few hours to prepare a description of the flow of interaction between the system and external actors
  • Groups of three go through the usage flow to come up with Actors (users and systems), Domain concepts (classes) or Containers (deployment diagram) mentioned or implied in the usage flow and write these on sticky notes. After showing the Actors, Concepts or Containers to the whole group, each workgroup then organizes these on flipcharts to create a Context Model, a Domain Model and a Deployment Model.

Many of these workshops can also be run with distributed groups over video conference and screen sharing.

I like to collect all of these artifacts (vision, users, usage flow, context model, domain model and deployment model) in a PowerPoint presentation so it can be easily showed by the team to external stakeholders. Sometimes someone on the team feel that photographed flipcharts with sticky notes are too informal and decide to draw something in Visio or another fancy tool. This is just a plus.

By asking the team to produce something and present it, rather than explaining the architecture to the team, I ensure that the information is really in their heads and not just my fooling myself by my own understanding.

Posted in English, Extreme Programming, Non-technical, Software Development | 3 Comments

The Rainbow Sprint Plan

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you.

Here is an example of a Rainbow Sprint plan:

  1. A customer wants cheap vacations
  2. The customer signs up for daily or weekly notifications of special flight offers
  3. Periodically the System checks which customers should get notifications
  4. The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system
  5. The System notifies customer of any matching offers via SMS

    1. Variation: The System notifies customer of any matching offers via email
  6. The customer accepts the offer via SMS
  7. The System books the tickets on behalf of the customer
  8. The system confirms the booking by sending an SMS to the customer
  9. The customer can at any point see their active offers and accepted offers on the system website
  10. The customer enjoys a cheap vacation!

What you can see from this plan:

Use case overview: The plan gives a high-level picture of the next release. We can see how the work we are doing is fitting together and how it ends up satisfying a customer need. This is a requirement technique that is basically Use Cases as per Alistair Cockburn’s “Writing Effective Use Cases“. I’ve been writing use cases at this level for the last three years and found it to be a good way to understand requirements. The trick of good use cases is to stay at a the right level. In this example, each step is some interaction between the system and a user or the system and another system. How this communication is handled is something I find best to leave for an individual sprint.

Iterative completion: Each step has a color code:

  • Black: The team hasn’t started looking into this
  • Red: We have made something, but it’s a dummy version just to show something
  • Orange: We have made something, but we expect lots of work remaining
  • Yellow: We’re almost done, we’re ready to receive feedback
  • Green: Development is complete, we have done reasonable verification and documentation

So the plan accepts that we revisit a feature. As we get closer to the next release, things will move further and further into the rainbow. But we can choose whether we want to get everything to orange first, or whether we will leave some things at red (or even black) while bringing other steps all the way to green.

Demonstration script: When we get to the end of the sprint and demonstrate what we’ve created, this plan gives a pretty good idea of what the demo will look like: We will sign up the customer to a dummy signup page (red), we will register some flights in another dummy page (red), trigger the actual scheduling code (orange), then we will see that an SMS is received on an actual phone (yellow). Then we will simulate an SMS response (orange), see that they system made some communication to a dummy system (red), and send “ok” back as an SMS to the customer (orange). This will focus the team around a shared vision of what to do in this sprint.

I have been thinking in terms of a Rainbow Plan in my last projects, but I’ve never used the term before. I think the plan addresses three of the most common problems that I see in Scrum implementations:

  • The team doesn’t see where it’s going, because user stories are too fine grained to get the big picture. User story mapping and use cases address this, and rainbow plans put it into a sprint-context
  • The team dives into technical details during sprint planning. With rainbow plans, the sprint plan becomes the demo plan which coincides with the requirements.
  • The project has a purely incremental approach, where each feature should be completed in a single sprint. This means that it’s hard to keep the big picture and the product owner is forced to look for even small bugs in everything that’s done in a sprint. With rainbow plans, the team agrees on the completeness of each feature.

May you always become more goal oriented and productive in your sprints.

Posted in English, Extreme Programming, Non-technical, Software Development | Leave a comment

How I debrief workshops

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others.

  1. I give everyone sticky notes with three colors
  2. I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.
  3. Everyone puts their sticky notes on a flip chart. As people come up, I read through their notes and pick out some notes that I think were interesting to discuss
  4. When everyone has put up their answers, I read up 1-3 notes about what surprised the participants, 1-3 notes about what they learned and 1-3 notes about what they plan to use it for. I comment on these results.
  5. As I end the workshop, I tell everyone “now, pick up the note with your plan as you leave the room and put it in your pocket. When you find it in the future, ask yourself whether you have completed it, or whether you should put it back into your pocket

"What surprised you", "what have you learned", "what do you plan to do"

I feel this gives a nice closure to the workshop and a drive for people to apply what they’ve learned. Have you been to one of my workshops where I had this debriefing? I’d like to know whether you used the “what do you plan” note. :-)

Posted in English, Non-technical | 1 Comment

Digital natives

  1. We were taught to categorize, but we know that searching beats sorting
  2. We were taught that information is scare, but we know that the real problem is too much information, not too little.
  3. We were taught that information must be protected from being viewed, but we know that the greatest threat to information is irrelevancy
  4. We were taught to estimate and plan what the marked wants, but we know that our customers don’t behave according to our plans
  5. We were taught to guide our customers, but we know they want to serve themselves. And they don’t want to wait for a sales clerk.
  6. We were taught to use use tools that reside on our computer, but we don’t use the same computer for long and we don’t work alone. We use tools that reside on the web.
  7. We were taught that companies are trustworthy, but we’ve learned to trust the voices of named individuals.
  8. We were taught that our value is determined by what we have, but we’ve know that our value is determined by what we give away
  9. We are the digital natives and we were not taught how to live in our world
Posted in English, Non-technical | 3 Comments

Tell a story with your project plan

This blog post is a summary of my lightning talk at XP2011

I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box. Or even worse: In an issue tracking system. Using the form of use cases, a requirement form that had failed me in the past, I have reinserted the drama into my projects.

Humans have used stories to communicate and to think about the world for as long as we’ve had language. Some elements are common to all stories: A conflict upsets the order of the world. A hero enters the scene. Through the actions of the hero, the world is set back into order and the all is well in the world.

Here is a for a project that makes a webshop, the story of desire:

  1. Some person craves stuff (the conflict)
  2. The webshop(the hero) welcomes the craving user to its front page
  3. The webshop lets the user picks stuff
  4. The webshop lets the user pay
  5. Some more stuff happens through the webshop so that the stuff is delivered
  6. Even more stuff happens
  7. The craving person gets his desire fullfilled and the world is set back to the way it was supposed to be

Not the most exciting story, you say? Well, you asked for software system requirements, not for literary masterpieces! The use case illustrates my point: A narrative lets us understand the purpose of the system (the hero) in the world and the operations the system needs to perform in order to fulfill its purpose. The first and the last step of this narrative happen without reference to the hero, setting the stage and providing the coda (look it up!), respectively. Each of the action steps between clearly states what sort of capability needs to be built for the system.

The story of desire is a made-up story to illustrate the point. Here is a simplified version of a real story in my current project – the story of disturbance:

  1. There is a disturbance in the balance of production and consumption of electricity (the conflict)
  2. Already, the system (the hero) has received from power plants information about their reserve capacity (this is a story of its own, but for another day)
  3. The system shows the Operator (the real hero!) power plants with reserve capacity
    • Variation: The operator filters the list of power plants using some criteria
  4. The system lets the Operator activate the reserve capacity at a power plant
  5. The system sends an activation request to the power plant in question so they can be activated
  6. The system shows the operator what reserves are currently activated
  7. The system lets the user deactivate reserves
  8. The system sends all activation requests to the accounting system, so the power plant can get paid
  9. The balance is restored

If you wonder why this disturbance in the force is a bad thing, take a look at my blog post about xxx. You’ll quickly see that the balance of electricity may impact whether or not my beer stays cool. Clearly an important concern.

This story is a bit messier, since it deals with more real-world problems. Together with all the details I let out, it also has the disadvantage that it will take one team about a year to develop. Our customer is a bit too eager to get some software out the door to wait for all that.

So, we present: The impatient story of disturbance

  1. There is a disturbance in the balance of production and consumption of electricity
  2. Already, the system has received from the old system we’re replacing information about power plant reserve capacities
  3. The system shows the operator power plants with reserve capacity
    • Variation: The operator filters the list of power plants using some criteria
    • Variation: The system updates the view it receives new reserves
  4. The system lets the operator activate the reserve capacity at a power plant
  5. The system sends the information about the activation to the old system we’re replacing for further distribution
  6. The system shows the operator what reserves are currently activated
    • Variation: The system shows the operator what reserves have been activated at a given power plant
    • Variation: The system displays a chart of what reserves have been activated at a given power plant
  7. The balance is restored

During the start of our project we wrote about 10 stories like the original story of disturbance. The stories were written by small gangs each consisting of developers and users or other domain experts. The gangs would swap stories and improve each others work. Meanwhile, the product owner and the project architect would try and pry apart a story so it could be delivered by a single programming team in the order of about 4 months.

For a single delivery, we would write an impatient story. Each action step or variation of the “impatient story of disturbance” became an item on the backlog of the programming team. I’ve left out about a thirds of the stories to keep the text of the blog post down. In addition, the team had about 5 technical tasks, such as performance testing. Each week, the team would deliver on average two such items.

After a few months, we have delivered the first increment in a system that tells a new story to the users, but a story they recognize. We have taken the task that they use their existing system for the most and made it easier and faster to use. The result: Happy users. And cold beer. We hope.

Notes

This approach has very much the same vision as Jeff Patton’s user story mapping and Effect maps. The approach of linear textual stories is one that works well for me. I urge you to find an approach that works even better for you. My stories use Alistair Cockburn’s style of use cases from “Writing effective use cases”, but with one changes: I simplify the writing of variations to better support the linear flow and avoid detail. They are roughly at what Cockburn describes as “kite level”.

Posted in English, Extreme Programming, Non-technical | Leave a comment

The value my system delivers: Keeping my beer cool

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement”

What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool.

Skill

If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it. Maybe you ended up writing code that didn’t compile and you had to throw it away. Maybe you ended up staring at an empty screen for hours waiting for inspiration to strike. Maybe you ended up writing a long document, only to forget to save it and then your computer crashed.

The first trick to making sure that your work is worthwhile is to make sure that the effort you put in actually transforms to some effect. In order to achieve this, you need experience and practice with your craft.

Purpose

If you don’t know why you’re doing what you’re doing, you may produce a lot, but it ends up not being valuable to anyone. Maybe the code you write solved the wrong problem. Maybe your long document didn’t answer the questions of you readers.

The second trick to making sure that your work is worthwhile is to make sure that the effect you have actually produces value. In order to achieve this, you need to move in the right direction.

skill transforms effort into effect; purpose transforms effect into value

This is the model of all human industry, whether you’re making cars, books, food, presentations or software.

In software development, effort is the time you put in, skill is your skill as a developer, effect is the working software, purpose is the architecture and value is the business goal.

The fast track to success is to understand the last step: Value.

“The other me”

Here’s an example. Find the value:

My current project creates a system which presents in user interface electricity reserves and planned electricity production that it has received from a message gateway, as well as measurements that it has received from an electricity management system.

This is gobbledygook. If this is how I see the system, I will fail.

In order to see the value, we have to take a step back. The system receives planned production and available reserve capacity from power producers. It presents this, along with measurements of the current balance between consumption and production on the electricity grid to an operator. The operator uses the reserves to regulate production to match consumption.

Hopefully, this is much more understandable. You’re probably aware that there are companies that produce electrical power, and you probably understand that electricity consumption should match production.

But why?

The ultimate value of the system is to the consumer who want to plug his appliances into the grid and have them work. They should neither blow up (too much production) or lose power (too little production).

Who is this mysterious “consumer”, then. Why, it’s me! It’s not Johannes-the-software-developer, it’s the other me. The “me” who has his fridge connected to the power grid so I can keep my beer cool.

The purpose of my project is to keep my beer cool.

The other you

To understand the purpose of your system, you should try and see how it contributes to your own life. Not the life of the “you” who develops software, but the “you” who uses electricity, the “you” who drives a car, the “you” who breathes fresh air, the “you” who wants to retire at some point in the future.

If you can’t see “the other you” in your system – take a step back and look again. If you still can’t see “the other you”, maybe you should be working on a different project.

Posted in English, Non-technical, Software Development | 1 Comment