Feature Centric Development, part II

In my previous post about Feature Centric Development (FCD) I posted the perhaps somewhat rhetorical question on whether FCD is simply the renaissance of top down functional decomposition, hoping that someone would jump in and challenge that claim.

And now my friend Anders, senior developer in a world renowned computer games business,  has indeed challenged my position:

“I’m not sure I see the parallels here. Is it not a superficial resemblence 
in two different things, team organization and software analysis methods? 
I’ve seen compartmentalized ownership under functional paradigms. “

Indeed! While it on the surface might seem that FCD is closely related to functional decomposition, it’s not: in fact, FCD is an instance of “organizational architecture”, while functional decomposition is an instance of “system or software architecture”.

Organizational architecture is all about how we organize the work of the individuals, groups and teams, what processes we use, and what organizational structures/patterns we employ.

System and software architecture is all about how we organize the system under construction, i.e. about structures, patterns, interfaces, behaviors and constraints.

Thus, FCD and functional decomposition do not live in the same domain, in fact, they are orthogonal (as indicated by Anders’ comment above).

So, we have two orthogonal dimensions or categories at play here, one dealing with how our system (or software) is structured, one that deals with how our organization and our processes are structured.

In the first category, about system architecture, we encounter acronyms and concepts like OOA, OOD, OOP, SOA, functional decomposition, modularity, cohesion and coupling, client-server, various programming models such as concurrent programming etc etc, while in the second category, we encounter concepts such as “waterfall”, iterative/incremental development, RUP, Agility, Scrum, XP, Rapid prototyping, FCD etc.

A number of years ago, I wrote a paper called “What makes software so hard ?“, where I introduced the notion of “doing disciplines” versus “supporting disciplines”, which in hindsight seem to be at least somewhat related to the two categories of architecture described here.

About swdevperestroika

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

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s