Blog

YAGNI – You Aren’t Going To Need It

The easiest way to save money and time building software products is to only build things that are absolutely essential. More features and frameworks means more code to write, more code to test and more code to go wrong. The cost of ownership of larger code bases is generally higher because they are more complex and there are opportunity costs for every feature implemented.

The Agile Manifesto has twelve principles and arguably the single most transformational thing it states about building software is:

Simplicity–the art of maximising the amount of work not done–is essential.

Ian Thomas made an excellent presentation at Agile Yorkshire about the cost of gold plating solutions and living by the YAGNI principle.

Using Hoshin Kanri to Becoming a Lean Enterprise

Achieving strategic business goals in constantly changing environment is often compared with steering a ship through a storm. Heading in the best overall direction is important while at the same time reacting to the the weather and each breaking wave. Hoshin Kanri is an approach to planning originating in Japan literally translated as strategy deployment.

Karl Scotland is an regular conference speaker and lean consultant who presented at Agile Yorkshire on this topic and how it can support the idea of learning organisations.

An Agile in the Public Sector Experience Report

IT projects within the public sector come in all shapes and sizes but have historically been harness to a set of procurement rules and practices that many people criticise for hindering and not helping the best outcomes. Things are changing however and approaches used within the private sector are slowly being adopted.

Matt Barnaby shared some of his experiences from public sector projects and reflects on the good the bad and the ugly to the assemble Agile Yorkshire community.

Developing HTML Forms

Developing useful and professional HTML forms requires a lot more work than simple examples might suggest. There are a whole range of problems such as handling initial data, client-side validation, server-side validation, optimistic concurrency and performing the final action. This post explores the various steps.

The initial GET request

The initial GET request is a simple subset of what we need to consider. This is made up of two parts:

  • Load any initial data and convert it into a form suitable for rendering.
  • Render the form as HTML and transmit that to the client.

Gathering initial data is simpler for forms that are initially blank. Forms that provide editing will need to get the original data, convert it to a values that are suitable for HTML inputs and then render the form.

The POST request

When users fill in the form they post their results back to the server. Regardless of the client-side code, we need to do a number of things.

  • Parse and validate the entered values.
  • If valid, perform the intended action.
  • If invalid, render the form with error information.

If the intended action is an edit to an existing logical record, we might need some of the original data from the database, and we might need to convert the POST data into a form suitable for our application or database.

If the data is invalid then error information needs to be rendered back with the fields. You need to know which fields are invalid and how to help the user to correct what they’ve entered, and this needs handling in a way that can be rendered back into the form.

Converting data

HTML forms support key-value pairs or text, that’s it! Any structure is purely coincidental and is not understood by the browser. There is also support for files, where the value is binary and comes with a content type, but that’s beyond the scope of this post.

Often, when working with structures data such as objects and arrays field names can be generated according to a pattern. Using Node JS modules such as flat help with bi-directional conversion of structures. More complex conversions will involve numbers, boolean and dates.

The conversion only needs to be done on valid data. If you are converting invalid data it is often a mistake.

Rendering and validation

Rendering is needed for both the GET and POST requests so it makes sense to use the same trunking to do this. The only real difference is that the POST request involves rendering error information. This is where forms get complicated as you might add classes to fields to show their status and include a header with more complex information.

You might also have some optional client-side helpers that make the user experience better and provide client-side validation and assistance.

The validation rules are often rendered to the client as HTML5 or ECMAScript but must also be enforced on the server to avoid security issues. Inconsistencies in these rules create opportunities for users to exploit the system and for valid data to be rejected.

Keeping an abstract data structure that represents the fields, their validation rules, rendering hints, current value and any error status, makes it easier to develop rendering templates field and provide consistent rendering and validation for all conditions and field types. It also  makes debugging much easier as you can inspect this structure more easily that looking at the complex HTML output.

Optimistic Concurrency

Optimistic concurrency is extremely important when editing data on the web. It allows people to modify data out-of-process without the server keeping locks.

There are two common models, although sometimes something more complex is done, these are:

  • Fail if modified and
  • Last one wins.

The first approach requires sending information with the form that lets you determine if the data on the server has been changed by another user or process since the form was presented. This might mean a hash or revision identifier of a logical record, such as that used by Couch DB, or it might be a complete copy of the original data so that data can be individually checked.

The second approach is simpler and often the most appropriate, depending on the granularity and nature of the data. With either approach, one user loses out, the difference with this approach is that the first user loses and doesn’t get to know about it. When considering how and why data is updated there are many scenarios where forcing the second user to lose and try again gives the same result as ignoring what the first user did.

Some database technology includes optimistic concurrency systems. It is often useful to combine the initialisation step into the POST request to get what we need to overwrite existing data without error, especially when implementing a last-one-wins approach.

Finally

This post has been written to cover some of the issues that can arise when developing HTML forms, it is not comprehensive and assumes the usual level of support in your HTTP server for dealing with general HTTP request handling issues.

Teamwork – Conflict doesn’t have to Mean Confrontation

Great products are built by teams not individuals and creating teams that work together really well takes a lot of work and effort from everyone involved. At the very root of everyone are their values and beliefs and teams often start to perform well when they coalesce around some values all the members share. That doesn’t mean disagreement or even conflict doesn’t creep in, it may often to necessary to reach the right solutions but with appropriate behaviour it doesn’t have to come with confrontation or conflict.

Adrian Frost and Ian Franklin are experts in this space and lead a discussion on the subject at Agile Yorkshire that triggered some great dialogue and learning for the group.

Is the Product Owner an Anti-Pattern

The role of Product Owner was first defined as part of the Scrum agile product development method. The current definition says – “a Scrum Product Owner is responsible for maximising the value of the product resulting from the work of the Development Team”. However typically this is a role that is much easier to talk about that actually do and here John Le Drew shines a light on some of the reasons for this and ask the Agile Yorkshire community for some of their experiences and observations.

An Introduction to the Cynefin Framework

The Cynefin Framework is a decision-making model used to help understand complex systems. The phrase “complex system” has particular meaning within the framework and has usefulness to software systems and the organisations that build and use them. Of particular note is that the Cynefin Framework is used to understand things in an emergent way adapting as new data arrives.

Detailed knowledge of the Cynefin Framework requires more time than is available here but Ian Lister provided introduction to the Agile Yorkshire community and hopefully offered enough insight to prompt some to investigate further.

Communicating to Stakeholders, Tell Stories Not Data

Communicating technical information is a challenge for anyone and especially to a non-technical audience. When the people being addressed may have a mix of backgrounds and focusing on outcomes or consequences and not abstract figures or engineering details, crafting the right message is extra important.

Ivor Tymchak, an expert public speaker and Bettakultcha co-founder, held the Agile Yorkshire audience in his hand as he shared his insight into story telling as the vehicle for this kind of communication done effectively.

A Humane Approach to Organisational Change

Organisational change is seldom popular. However all organisations exist in a changing world and must constantly change and adapt to what’s around them and the market conditions that prevail. How an organisation adopts change preoccupies many management teams and whether their strategy is top down, bottom up or some other approach the tactics must keep the employees engaged and moving in the right direction.

Author of several books on lean / agile adoption and founder Agendashift, Mike Burrows visited our Agile Yorkshire event to talk about effective and human change with IT organisations.

Ideas on How to Split User Stories

Breaking large user stories (or work items in layman’s terms) down into several smaller ones hugely improves delivery predictability. There are several reasons for this including the fact that smaller items with fewer moving parts are simply easier to estimate for humans. There are fewer problems to solve, fewer assumptions to get wrong and fewer things to overlook. it’s common to hear developers saying things can’t be broken down further, however this is rarely the case.

Breaking things down does require practice and a little creativity to ensure each item still provides business value but is independent enough to be moved up or down the list of priorities when adapting to business needs. Tony Heap provided a great list of tips and techniques for breaking down user stories in his session at Agile Yorkshire. This list isn’t exhaustive but cover many of the most common situations.