Tag Archives: kal nasser

Do ‘Agile’ Methods for Software Work?

Past wisdom in software development held that the proper sequence of events should start with perfect requirements, followed by perfect design and planning, ending with implementation. The flexibility promised by agile methodologies of software development, according to that view, is as costly as allowing for the possibility that the kitchen in a half-built house is not in the desired location. Besides, what is the meaning of software “architecture” if we allow for shifting designs and evolving features?

To answer the criticisms about agile developments, one must examine the underlying concepts supporting traditional, sequential “waterfall” development:

  • Perfect planning is possible;
  • Change is inevitably costly;
  • Architecture must result in unchangeable results

But perfect planning isn’t possible. It is a disservice to the client to require a perfect plan. In the real world, knowledge of the business is dispersed among many stakeholders; concepts suffer from varying degrees of vagueness; and the desired outcome often begins to crystallize only after the work has begun. It is therefore more cost-effective to have  technical talent that can function in an interactive environment with the stakeholder and adapt the work to an evolving plan.

Change isn’t always costly. The cost of change can be minimized if enough flexibility was implemented in the first place. Planning must therefore allow for the ability to make changes. The extra initial cost reduces the risk of a higher cost being incurred later.

Architecture does not equal rigidity. Proper software architecture makes use of techniques that reduce dependencies, generalize software components and anticipate changes in the design itself. To continue the half-built-house analogy: The ceiling is not resting on too many walls, and the infrastructure for the kitchen is in many places in the house.

The practice of writing flat, unidirectional software, based on the theory of the “perfect plan” has resulted in legacy software that is hard to change, maintain or understand. The evolution of the software engineering discipline is in part a response to that problem. The common threads in modern software design concepts indicate that.

For example, the concept of encapsulation in object-oriented languages, where the inner workings of a software entity make that entity a black box that can be replaced without having to change its context, directly serves the need for flexible architecture at the lowest level. The concept of “pure functions,” in functional languages, where a function is by definition unable to change its environment (making the function easy to “unplug” and replace), also serves the same end.

Proper architecture makes use of established and proven design patterns, selects the right patterns for the task at hand and adapts them when needed based on the specifics. This increases the effectiveness of the planning stage by a) avoiding reinventing the wheel and b) greatly reducing the number of possible paths that need to be explored.

It takes a certain attitude to embrace the agile approach: one that thrives on innovation, freedom and work that never stops improving.

Translating Business Logic Into Code

Imagine a science-fiction novel involving a computer that becomes independent of humans. It runs their affairs and takes care of their lives, but few, if any, know its inner workings.  But that isn’t science fiction. There are lots of business systems that no one fully understands, designed by people who no longer maintain it, encompassing business logic that was dictated by people who are long gone. In both scenarios, we are at the mercy of a computer. In the first one, Arnold Schwarzenegger saves us. In the second scenario, a humanoid robot won’t do.

Enterprise software development comprises understanding, documenting and implementing business logic, which is the human process the software is supposed to automate. And yet, one of the often neglected links in the chain of skills that software developers possess is the business side. Understanding of the business is necessary to keep the underlying software connected and to stop it from becoming an isolated, unreachable island over time.

This skill does not come naturally or derive inevitably from a technical background. Despite the name, “There are few things that are less logical than business logic,” software guru Martin Fowler writes. Business logic lacks the determinism of functions and conditional paths and the clear-cut rules of Boolean logic. Business logic is the creation of sales and marketing, not mathematicians and software engineers.

A “hybrid-professional” is needed: someone who knows the business and the technology. The benefit of this approach may not be obvious. After all, division of labor exists for a reason, and specialization is due to the limited capacity of individuals and time available to them. Without specialization, major human endeavors wouldn’t have been possible.

There are, however, certain scenarios in which strict specialization is more of a barrier to progress than a facilitator. Enterprise software is an example.

On the surface, the delineation seems natural. The business people know what the business logic is, and they deliver it to the developers in the form of requirements. The developers then translate the requirements to software.

The weakness of this approach is the direction of the translation. Distilling the business process to a set of requirements by a non-developer necessarily deprives the developers of the big picture, so they will write software based on the pinhole view given to them.

It’s like translating text from a foreign language. The message, more or less, can be conveyed if you translate word by word, but to fully appreciate the original content you have to understand the original language in its cultural context.

So developers need to understand business language and directly engage the business side. This approach seems to be merely a reversal of direction. Instead of having the business side deliver the requirements to the technical side, we would be doing the opposite.

How is that better? It is better because the end product lies at the technical end, not the business end. We’re trying to build software to accommodate the business, not the opposite. That dictates the direction, and it makes all the difference.

Business people excel at business, and they do it without worrying about how their decisions will translate to software. It is best to free them from that worry — unless the business itself is software!

Software developers have to worry about the software they create. Because one of the two groups has to be burdened with both sides of the equation, the latter is the natural candidate.

So the ideal hybrid-professional is one with solid roots on the technology side and the skill to venture into the business side and obtain insight into the specific business domain she is developing for. That skill is made up of people skills that complement the “machine skills”; the ability to compartmentalize technology so it doesn’t pollute or dictate the business model; and having true insight, not just knowledge, into the business domain, so that there is never anything lost in translation.