Sadek Drobi’s Blog

Today, many software project management and architecture approaches tend to parcel out  work on a project creating hierarchical layers. This helps to simplify both developers work and management. However, the undelying information shielding among layers can  potentially create a gap between developers and the software they are working on, if developers task are totally taken out of functional context.

Many efforts in today’s software community are targeted at bridging the gap between software professionals and business people. Several blogspace authors look at the issue from a slightly different perspective, highlighting the gap between developers and the software they are building.

According to Jeff Attwood, Amazon’s experience of regularly involving its developers with costumer service is a valuable means for improving quality and usability of software.  He believes indeed that “all too often, software developers are merely tourists in their own codebase” because they lack a basic understanding of software users, their problems and concerns. This is what he has earlier referred to as  “ivory tower software development”:

In the absence of any other compelling evidence, developers assume everyone else is a developer. [...] The more isolated the developers, the worse the resulting end product. It doesn’t help that most teams have a layer of business analysts who feel it is their job it to shield developers from users [...] It’s dangerous to create an environment where developers have no idea who the users are.

However, today’s industry is characterized, according to Abhijit Nadgouda, by hierarchy, existence of multiple layers and information shielding among those layers. He highlights that this simplifies management and makes business safer, but has rather negative implications on software quality:

We create a hierarchy in our projects, and every level shields the lower levels from some information. How many members of the software development team know value of the software they are working on, or its importance to the client’s business? How many of them even know about pieces other the one they are working on?

[...]

There seems to be a disconnect between better business and better software development. Which is why, I believe, most of us are doing good business, but we as an industry still stink at software development.

In his attempt to identify the reasons why “we still stink at software development”, Reg Braithwaite also raises this issue arguing that it might be wrong to divide up work on a project in a way “that the people with the least experience are protected from damaging the code”.

Architecture based on such approach tends to simplify developers work through abstaction. If this is pushed to the extreme, developers tasks are taken out of functional context to become purely technical, which can potentially create a gap between developers and the software they are working on.

What is your opinion? Is such a protectionist architecture an impediment for software usability? Can architecture with developers ignorant of the full picture be effective? Does it deliver sofware and value?