1 Hermeneutics in Agile Systems Development

The systems world is moving toward agile development methods.This book is about Agile Systems Development.

Agile is the new world view of systems development. Structured design is now relegated to systems that have a short development time, the way to develop the software is already known (there is no need for design), and the system will not change in any way during the design.

Agile methodologies have been developed over time from developers experiencing success by rejecting the ideas of the structured methodology and the waterfall style of project management.

The main strengths of Agile methods are:

Visibility (through the looking glass)

Adaptability (context calculus)

Business Value (incrementally increasing the value)

Less Risk (changes are made on a Just In Time bases)

The biggest problems with the waterfall techniques are:

Risky and expensive.

Inability to deal with changing requirements.

Problems with late integration.

Always required extensive rework to make software usable

Business advantages of Agile development:

Benefits can be realized early.

First to market and early and regular releases.

Testing is integrated so there is early recognition of any quality issues.

Excellent visibility for key stakeholders ensures expectations are managed.

Customer satisfaction through project visibility customers own the project.

Incremental releases reduce risks.

Change is accepted, even expected.

Cost control - the scope and features are variable, not the cost.

Developers feel that they are part of the project and enjoy doing the work.

In agile development ou are using post-modernist methodologies. Agile is post-modern or post structural. Agile was designed to set aside the structured approach. That goal was the exact goal of post-modernism. Agile and quality-productivity are the most effective post-modernist movements.

Structured design is now relegated to systems that have a short development time, the way to develop the software is already known (there is no need for design), an the system will not change in any way during the design.

There are numerous agile design methodologies. These seem to be quite different in application. This textbook examines the agile process and develops a concept of how agile works in general based on context calculus and 'through the looking glass'.

Context calculus emphasizes the multidimensional character of both the systems problem and the systems solution. Context calculus is the calculus of contexts. This is the philosophical basis for the spiral iterative process used in agile methodologies. It refers to the incremental and iterative way of solving problems where there are multiple contexts involved. Incremental and actual changes and improvement are combined to create useful solutions to real problems.

'Through the Looking Glass' emphasizes the need for openness in developing software, which is a central theme in agile. Through the Looking Glass is a rule requiring openness and visibility of all efforts, to everyone involved, related to solving the systems problem. This includes making sure all stake holders completely understand and are part of the process of developing the solution. This openness of the agile methodology provides the basis for customer satisfaction, project communication, developer motivation, and the re-usability of the resulting software modules.

Through the Looking Glass

The mathematics of database design was relational algebra. This was a set of concepts that led to the design of databases as relational. The basic principle of this was that a query on the database should be written in plain language, thus the relationship of tables in the database could be called relational to the extent that including more than one table in a query did not result in the necessity of navigation in the query language. That meant the person querying the database did not have to specify detailed directions on how to get from one table to the other. The tables were relational so you just named the two tables in a join statement. There also was a need to express how to navigate through the join. Navigation is the problem you have with non-relational databases. In non-relational databases, you often need to access each joined record with a different algorithm, so the query would require search and sort language; this language is definitely not like normal English (or French, or whatever language).

For the development of the rest of systems processes this kind of goal has not been as clear. There are a whole list of separate goals and, at this point, a lot of different processes and even methodologies to work with. There does not seem to be a mathematics of systems design as there is with database design. What is the basis for developing such a mathematics?

The areas to look at involve the way we use systems. Codd was trying to define the use of databases. With Yourdon and structured system design the idea was that functionalism was the basis for design. Perhaps we could then talk about functional algebra. But the ultimate meaning of functionalism was that people would be replaced by computers. Even though this goal was not talked about, for good reason, it was a main part of the structured methodology. But people were not being replaced and there was often a need for more people –perhaps with different skills. There will always be people around.

So we do need to include people in the development process. Knowing how people use computers, and how people can improve their use of computers, is part of the design mathematics. Almost everyone is using computers today because computers are usable, usable by people.

We also need to include the fact that computers do processes. The processes that computers do best are often the processes that people don’t do as well. Whatever the mathematics we develop it must examine processes that can be improved by computers (this is the area that structured people were focusing on when they developed functionalism as the “only” goal of system design). Actually to avoid the difficulties that structured methods caused in this area we should refer to this area as activities. Processes are functional; activities may or may not be functional. And computers can do activites.

There is also an existing structure to any area where we want to include a new computer system. The idea of structure includes the organization diagram; but it also includes the relationship of entities that are not people – both to each other and to the people.

Computers are now more involved with communications than processes. Computers do both but it appears that communication is becoming a prime activity of computer systems. A mathematics of systems design must include this important part of computer systems.

The mathematics also needs to include the status of the system the computer system is included in. The status means a system has states it can be in. The state a system is in can affect the processes that are done, and the necessary communication. These states also need to relate to the status of the real world system.

In any organization that requires a computer there is an existing portfolio. A portfolio is the compilation of all the systems, computer or otherwise, now available, plus all the documentation that is on file, plus all the records that are available and being used in the organization.

So there are a number of dimensions to this mathematics. There actually may be more than those mentioned, but this list provides a concept of the multidimensional character of the problem and defines much of the problem space.

There is a simple term to define all of these dimensions of our problem – that term is context. The design of systems must follow a context calculus

The basis of the context calculus is the derivative mathematics based on the looking glass. The looking glass is the interface between the computer system and the real world system. Now when you go through this looking glass – like “Alice through the Looking Glass” – you find that the world you have entered is the same in some areas, but strangely different in others. So this is the looking glass basis for the context calculus. As we look more closely at the problems of our transformations we find the need to study how the limit of smaller details on one side is mirrored on the other side in the change of its details. We do not solve systems problem if we do not resolve the details (to the limit) of the relationship between the two sides of our looking glass. The looking glass is the center of the differential calculus of the parallel world.

Now in the structured methodology the important side of this looking glass is that inside the computer. After all we were, supposedly, replacing everything else with the computer. So the virtual world became the center and driving force of the development. The real world was only a shadow of what was to be. In the more recent methodologies the real world becomes the important world and the computer world is a response to the real world. This allows us a better examination of the real potential of the virtual world and its relationship to the real world.

Hermeneutics in Agile Systems Development eBook on Software Development

Jerome Heath

Seven Covers

Jerome Heath Books

UberMann