Feature Centric Development – the renaissance of functional decomposition ?

With growing age, it becomes increasingly difficult avoiding to see many of the “new” trends and movements in our industry as anything else but “already been there, already done that”, that is, my argument in this post is that much of what on the surface might appear as a radically new process/methodology/way-of-working, in fact is a variation of something that’s already been used.

I thought I’d write a couple of posts on this topic, and to keep the discussion at least somewhat concrete, I’ll use Feature Centric Development as a recurring example to illustrate my point.

So let’s take Feature Centric Development (FCD) as a concrete example, and muse a bit around it’s characteristics, and where it might originate from.

The basic premise about FCD is that work should be organised around a “feature”, i.e. a piece of functionality/capability/service that has some value to a stakeholder, in many cases a customer, who would potentially be willing to pay for the feature.

So, we set up our organizational structures, our processes, and our teams based on the (abstract) feature.  Ideally, our tooling should also provide direct support for FCD. So, in an organization doing FCD,  everybody in the organization, every role should ideally talk, think, and act with the feature at the center, e.g. business execs should talk to the financial analysts in terms of features, the corporate bean counters should report financial results based on features, the sales guys should sell features, the analysts should gather market demands and customer requirements in terms of features, the product managers should plan products and production in terms of features, the system architects should design the system based on a continuous growth of features, and the developers and testers should construct and test the features.

Do you see this happening in your organizations ?  I don’t. I see parts of the above scenario happening, but what I mostly see is that the FCD movement (as well as the Agile movement in general) is a strict “bottom-up” movement, i.e. IMO, FCD as well as Agility is a “grass root” movement, starting at the organizational leaf level, and slowly moving upwards the organizational hierarcy, but fairly soon coming to a stop. Businesses at large tend to still be very much non-FCD and non-Agile, still operating very much in traditional waterfall:ish style, organized in functional or product based silos.

So, where does feature centric development originate from, what are its roots in terms of software development / software methodology “philosophies”…?

First, it’s obvious that at business level, FCD (like any other “philosophy”) is a result of the ever increasing business pressures to achieve better productivity, Time-to-market, and quality, that is, FCD is now seen to hold some promise to increase the competitive edge.  Whether that will happen or not, remains to be seen.  But the more interesting question is to examine the technical heritage of FCD.

Perhaps it’s easiest to explain by exploring a bit of the software development philosophy/methodology history from the past 30 years or so: when I took my first stumbling steps in software for more than 30 years ago, when men were men and software development still a craft, software was done by individual experts, gurus living in data centers who knew how to use a slide ruler to check computations, and how to punch holes to a program card, or how to boot a machine by entering the boot sequence on the front panel switches. These guys sure could hack, they were the real hackers before the term hacker became negatively tainted. Typically, programs (as well as machine capacity and power) were small these days,  so a typical program (“computation”) could be designed and implemented by a very small team, often a single guy.

Over time, the capacity of the machines grew, which resulted in that the programs that could be run on the machines also grew, which meant that the size of the development teams grew. Fast.

So, now the problem became how to organize and orchestrate the work of teams of hackers (sorry: programmers!).

Enter software development processes and methodologies!  (and very soon after, organizational functions/units with responsibility to create the mother of all processes/methods, but that’s an other discussion… 🙂

Among the first process and methodology “philosophies” I encountered for almost 30 years ago was waterfall (process) and structured methods (analysis, design, programming). Instances of these “philosophies” included standards such as mil-std 2167A, Structured Analysis and Design (SSADM) and others. Also in programming, structured programming came into vogue.  Thus, in simplest terms, as the software development world rapidly grew, the dominating “philosophy” for how to organize development was centered around “structured” functionality, with “top down functional decomposition” coming to dominate during the 80ies.

As always, sooner or later there’s going to be a backlash for the currently dominating “philosophies”, and in the world of software development, the backlash against “functional decomposition” really took off sometime early 90ies, when object orientation (OO) came to vogue. Suddenly, everything functional (I’m not talking functional languages now) or procedural in terms of methodologies was bad, and everything OO – analysis, design, programming) was all of sudden good.  The OO vogue also resulted in a huge interest in the architecture and design disciplines, and eventually this lead to an equally large interest in models, modeling and model driven development, and extensions of the OO paradigm, such as “component based design”.

So, during the 90ies, there was a war-like situation, with the front line sitting between the new camp who considered “things” (objects) as the #1 citizens of the world, and the old camp who saw “functions/processes” as the prime citizens.  Eventually, the proponents of the “things-camp” won, and the world of software has ever since the 90ies been dominated by the “believers-in-things”, i.e. the OO folks.

Now, with FCD taking off, it seems we are about to experience a renaissance of the “functional” philosophy from the 70ies and 80ies. If the typical organizational structure of the OO-based “things-camp” was a “component team”, the organizational structure of the new, FCD world is the “cross-functional-team”, and with the feature, i.e. a piece of functionality, now again being at the center, the pendlum seems to have swung back.

The interesting challenge now, for the organizations going FCD is to take the good lessons learned of the “things-focus” of the past 20 years or so, i.e. to integrate the lessons learned about the importance of architecture and design, into this new world of “fast functionality” and speed, so that the integrity of the architectures and designs can be preserved  – if that’s not done, I fear that the wins of the FCD paradigm, in terms of speed to market, will be very temporary, and major struggles will lurk under the horizon with large amounts of accumulated technical debt.

Advertisements

About swdevperestroika

High tech industry veteran, avid hacker reluctantly transformed to mgmt consultant.
This entry was posted in development, Organization, software and tagged , , , , , , . Bookmark the permalink.

One Response to Feature Centric Development – the renaissance of functional decomposition ?

  1. Pingback: Feature Centric Development, part II | systems-software-development-perestroika

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