User Tools

Site Tools


start

Flow-Design - Fluent software production made easy

Flow Design (FD) is a comprehensive approach to developing software in a sustainable manner. It ranges from requirements analysis to coding; it makes suggestions for how to design software as well as how to work together to produce it.

As the name suggests FD revolves around the notion of something flowing, be that data or work items. FD strives to make software development fluent in all aspects. Because fluidity to us seems the most desirable attribute of any production process. A continuous flow of valuable output, never stagnating while there is input, is observable and leads to revenue flowing back in return.

To us a sustainable flow of valuable and correct releases is the core measuring stick for the quality of any software development effort. And only if this flow stagnates motivation can be built up to change anything. Clean code principles and practices thus are only means to an end: sustainable production flow. The same is true for agile principles and practices.

We could even sum it up into „It’s the flow, stupid!“

But what is it that underlies and contributes to a sustainable flow of valuable and correct releases as output of the software production process?

A fluent process

Firstly fluent software production is about the „right“ process or an explicit process at all. Unfortunately we found the consciousness about such a process lacking in many teams. Sure, there are different activities making up software development. But should they be viewed as part of a production process like one for blow dryers or cars? We think, yes. It’s of great importance to be clear about this process and to visualize it and to observe it – in order to keep its fluidity high. As much as software development is a creative activity it’s one that’s under pressure to deliver reliable results in a reliable manner. So we included some recommendations regarding how such a production process could look like and how to organize the work within its frame.

Learn more at ROSD, short for Results-Oriented Software Development.

It all starts with the requirements

One of the requirements of fluent production is fine grained high quality input. That’s why Flow Design includes recommendations as to how to deal with requirements. How should they be processed to make it easy for developers to translate them into code and keep the release flow up? Simply writing user stories on index cards is not enough, we think. Requirements analysis needs to move closer to coding; it should make it as easy as possible for developers to continue after analysis with solution design. Whatever is the output of requirements analysis is at the interface between customer and developers. It needs to be tangible for both groups.

Learn more about the AnalysisPhase and Slicing as the initial joint activity of Product Owners and developers.

Think before coding

However, even the clearest requirements force developers „to make a leap“. They need to come up with an approach for a solution for the requirements. That’s the creative activity at the heart of software development. We have found, though, that this is equated with coding. But that’s a very expensive misunderstanding. Solution approaches are always conceptual and come before code, they are ideas, plans. Code (and the use of certain technologies) are just encodings of an approach. This is not to suggest coding was simple; it can be very difficult and require much experience. That’s why the misunderstanding is so expensive: Being only able to think of solutions in terms of code means to think of them in the hardest to change form. Code is never easy to read and not very malleable – compared to non-code solutions, to designs, to plans. That’s why there is great need for a method to design solutions before coding.

Learn more about how Flow-Design approaches the DesignPhase.

Clean code out of the box

Finally, how to create code for solutions? How to translate designs into programming language artifacts? This should be as easy as possible and directly lead to clean code (as much as possible). That’s why we provide specific rules to encode designs. They are to guide and bridle the use of programming language features. Coding to us is not a question of how to exploit as many features of a language as possible, but to apply them in a conscious way as to keep the code simple for those who later on have to read and change it. Code structure does not come from language features use but from design; language features serve designs, not the other way around. The code needs to mirror the design; but also code and design should not overlap.

Learn more about how to drive the ImplementationPhase starting from an explicit design.


Flow-Design is not a revival of the infamous waterfall process, even though it separates development into phases. Iterations are at the core of FD. Nevertheless the transformation of requirements into valuable software is viewed as a multi-step process to bridge the RequirementsLogicGap.

start.txt · Last modified: 2018/04/03 00:05 by fdadmin