Keeping the pace and being into it

The art of delivering wanted software

The first post will be about my preferred way of working with the clients to mutual benefit and build software that reflects its business.

What I would like to point out in the below article is balancing human and technical approaches to build a win-win relationship with the client and build great software.

The Foundation

Firstly it's worth emphasizing the significance of maintaining open, regular and direct communication with the client. Whenever I start a new project I first want to meet the person behind it, then the project. Ideally, it's great to have customer (product owner) on-site and collaboratively prepare together user stories. But if that's not possible then we can get the real feel of the project and the people behind it by listening when they talk about it and asking valuable questions; about the business, the project and its employees. Often owners of the businesses have a lot of things to say about it so try to narrow the conversation down to the environment in which future software will operate.

When we build a basic relationship and have enough knowledge about the project then we can start preparing the design for it. It starts with knowing the domain.

Being into it

When we have a basic relationship with the client and explained the way we are working on the software it is time to get to know the environment in which it will operate (a domain). By having a customer closely working with the software team on the domain modelling we ensure that it reflects the real problems which it's being designed for.

The domain contains the things and processes inside of the businesses that the software will model. That gives us a common language and a similar way of thinking. It also eases conversations with the customer about the solution and as a result, puts us on the right track.

The domain language should be reflected in the code by the modularization, naming convention and types of operations. It will make the life of developers much easier in constantly changing details of the requirements which are being discovered during the process.

BDD - Code that reflects the requirements

One of the classic approaches is writing user stories that are later translated into acceptance tests (Behaviour Driven Development). When those tests are written before any implementation using TDD or Test First approach it gives a perfect framework for writing only code that satisfies the requirements, straight to the point without any unnecessary lines.

The whole topic about testing is for another blog post, but these are the essential prerequisites that lay the foundation for success.

Keeping the pace

One of the inspiring approaches is Extreme programming (XP) which is an Agile project management methodology. It targets speed and simplicity with short development cycles.

We can keep up with changing requirements and discover the product with the client by having those small, frequent steps (weekly or bi-weekly) of delivering separate, working pieces of software. Some form of Scrum could be helpful here, but usually, a full-blown approach seems counterproductive.

An important part of having continuous feedback is showing at the end of every cycle demos of delivered functionalities and receiving comments from the customer.

Future reading:

• Martin Fowler - Domain-Driven Design

• Kent Beck - Extreme Programming Explained (Book)