//
you're reading...
SMART/Lean development

Lean Development – Challenges

Lean development principles focus on reducing waste to improve customer experience [ref ]. Some lean principles preached, such as “reduce waste in project management”, “amplify learning” etc require a change in the process followed to go from idea to delivery. But, principles such as “Decide as late as possible”, “Deliver as fast as possible”, “Reduce waste in code development”, “reduce waste in work potential” etc., forces us to rethink and implement a paradigm shift in the way we code a product and the platform on which we code the product.
Being able to develop a ‘new component in matter of days’ or ‘react to changes fast’ fosters delaying decisions as late as possible, hence enabling businesses to take more informed decisions. The best solution to “code fast” is to “write only the necessary code”. “Less Code” prevents loss of the “intent of the code” in the “noise” of the implementation. Less Code is good. It reduces waste, increases reuse, prevents duplication and is easy to understand and maintain.
To be able to reduce code, we need to look critically at the code that we as developers write. We need to evaluate the different pieces that increase code and rethink strategies and change architecture to reduce them, thus enabling lean development. Some of the first apparent thoughts here are:
  • Duplication of code due to technical concerns: 
Code for persistence, transaction etc are duplicated over and over again in all places where they are required.
Aspect oriented programming is a solution that helps alleviate some of these problems to an extent by separation of cross-cutting concerns [ref]. Yet, AOP retains the dependency of code on the AOP techniques. For eg., to be able to use spring framework we need to still scatter our code with “@Transaction” type of annotations. So while code for cross-cutting concerns has been reduced, it has not been eliminated. And it has introduced dependency on the library used.
  • No re-use of functional components:
We find a number of independent functional pockets exist such as metrics for an object, auditing of an object that are re-coded for every object in the system. Libraries exist that help us reuse code, yet require a tight integration in the form of calls to the function calls within the code.
  • No easy way of Web Enabling:
Modern application need to be visible over the internet or intranet using web technologies. This introduces a host of other requirements for coding where data needs to be exposed over the network. This forces developers to write new functional components, where posted data from forms in the HTML UI need to be processed and controllers written to direct them to the correct functional models.
  • No easy customization. 
Open source applications exist for the functional pockets. But these are rigid implementations with a host of generic functionality which needs to be adapted to our business environment. To be able to use these in a lean methodology that promotes “Amplify learning” by releasing small features at a time, requires small customization to be done on these open source functions which is time consuming.

Drawbacks in existing platforms

We find that such problems exist because no underlying platform exist which promote “Write Only Necessary code”. Platforms such as J2EE ease development by providing tools for mundane tasks, but does not completely eliminate the need to think about the cross cutting concerns and implementation details.
  • For eg., it provides a Servlet engine which helps web enabling, but servlets have to yet be coded and exposed via the web.
  • For a complex application that require asynchronous processing, it provides JMS queues, but it still expects the developer to use the tools, hence littering the code with post calls.
The “Write only necessary code” in these cases takes a back stage and the developer is forced to also write extra code required for the execution in a particular platform. The developer cannot concentrate only on business logic in the existing platforms.

An envisioned concept platform for lean development

To be able to  promote lean development, existing platforms need to move away from being a “container that provides tools” to a being a “container that hosts functional components”.  Shifting the perspective and redefining the concept of a platform from being a “technical container” to a “functional container” allows us to move from a “scale up” development (functions built over existing functions) to a “scale out” development (functions built independent of each other and can be mashed together to form a bigger function). In such an environment
  • “Business logic” is given prominence. This forces the platform to abstract implementation by adapting implementation details into a business logic, rather than forcing the developer to adapt implementation details (persistence, transaction, security etc) into the business logic.
  • The fundamental building block dealt with is a “Business function”. This automatically brings in “Loose coupling” of modular functions, thus reducing integration code present in a tightly coupled platform.
  • “Loose coupling” allows easy adding or removing of modular functions from a component, so that a single component can be easily varied with changing functionality.
See “SMART – a smart way to foster lean development” for an implementation of such a platform.
Advertisements

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: