10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Can architecture create a gap between developers and software they build?
Posted by Sadek Drobi on Dec 14, 2007
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 customer 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?
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
Case Study: IBM's Agile Transformation
Agility at scale, become as agile as you can be
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
I'm not sure that port is particularly relevant to the questions you ask
by
Reg Braithwaite
Posted
Re: I'm not sure that port is particularly relevant to the questions you as
by
Sadek Drobi
Posted
Heading for this topic is not appropriate....or is misleading...
by
Anilkumar GT
Posted
Re: Heading for this topic is not appropriate....or is misleading...
by
Sadek Drobi
Posted
Humans ...
by
Steven Devijver
Posted
Re: Humans ...
by
Sadek Drobi
Posted
Abstraction does what?
by
Jim Standley
Posted
Re: Abstraction does what?
by
Sadek Drobi
Posted
Re: Abstraction does what?
by
Jim Standley
Posted
Re: Abstraction does what?
by
Sadek Drobi
Posted
Re: Can architecture create a gap...
by
Andrew Clifford
Posted
Re: Can architecture create a gap...
by
Steven Devijver
Posted
Re: Can architecture create a gap...
by
Sadek Drobi
Posted
Architecture, design, etc... is not the problem
by
Amr Elssamadisy
Posted
Misconception...
by
William Martinez
Posted
Can architecture create a gap between developers and software they build?
by
Arif Budimartoyo
Posted
-
The post you mentioned, Something's Fishy, questions whether we can succeed by lowering the hiring bar. But it isn't really about architecture impeding value.
I would suggest that my thoughts in IT's time to stop blaming management are much more on-topic for your questions.
Thanks for thinking of my weblog, it is always interesting to reflect on the questions InfoQ raises. -
I agree with the observations made in this write up....but i feel that i has nothing to do with architecture....it has more to do with 'approach' that is taken by a company to build software systems....not with the architecture of the system being built per-se.
-
Thank you, Reg, for passing by and linking to your more recent post.
I agree with you that "Something’s Fishy" is not directly relevant to the main focus of this post. However, it seems to me that when you talk about “dividing up work on a project such that the people with the least experience are protected from damaging the code”, it conveys the same idea I was mentioning at that point.
Your more recent post was published after I finished my write-up. I decided not to add it because it rather speaks about the constraints architecture may put on innovation and flexibility. It is true that it oftentimes comes along with the fact that "developers tasks are taken out of functional context". Both are the result of the protectionist architecture I am talking about. But I decided to keep the focus on the gap between developers and the software they are building. -
You can't compare Amazon (or Google) to any odd project. First of all, they are developing PRODUCTS, not projects.
One can make the observation that there is no customer service desk on one's project. If it would be that simple ...
The root problem is the balance of responsibility. If one outsources a software development problem and one threatens to sue the contractor's *ss if one is not happy with the result then one shifts away the responsibility from one's self and in doing so one greatly reduces the chances for success.
If one has developers in house they can indeed hang out with the girls of the customer service desk.
Is it really any more complicated than this? -
If one has developers in house they can indeed hang out with the girls of the customer service desk.
Is it really any more complicated than this?
I love it! Here comes a solution :D !!! -
I agree with the observations made in this write up....but i feel that i has nothing to do with architecture....
Architecture plays a big role in organizing the software team. Plus abstractions should not yield complete ignorance of what you are abstracting. This applies to frameworks, APIs and services the architecture defines. That is why architects, in my opinion, should be careful on keeping developers aware of the whole picture even when abstracting implementation details and common domain properties. -
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.
This seems backwards. For me the point of abstraction is to encapsulate the technical and allow developers to focus on business. My goal is for every line of application code to sing about insurance.
There may be a gap between developers and the bit twiddling required to make some of the technical bits work, but whether that's a bad thing is another debate, going back to whether an assembler isolated coders from machine language too much. -
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.
This seems backwards. For me the point of abstraction is to encapsulate the technical and allow developers to focus on business. My goal is for every line of application code to sing about insurance.
Consider an example, and it is not the only one, an architectures where one of the goals is to be able to replace developers easily as resources. These architects do their design keeping in my mind that there is no time to teach the big picture to developers. That is when developers task turn to be technical and simpler but disconnected from the context. Or at best focused on a very small part of the whole system. It is not only about ignoring the whole business, but partitioning results in an ignorance of the rest of the world. There are a lot of examples of such architecture. -
Not than I am an agilist, but agile methodology goes a long way to deliver business value by having really good business/technical developers and tight integration into the business. The formula doesn't include weak people. I feel this is partly a reaction to the layered approach offshoring forces on projects. Offshorers may not understand the business need but they can knock out a technical spec.
With today's mature architectures, implementations like .net, java, and lamp all have well documented frameworks and best practices an architect should facilitate on projects not dictate.
Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck. -
Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck.
That's not very helpful advice. Layers are pretty abstract animals. They have elements of packaging, patterns and services. People attribute all kinds characteristics to layers.
It may be true (or not true) that focusing on layers has a tendency for failure. If you mean that layers should be abolished all together then this will lead to very poor code quality.
Not understanding layers may lead to rejecting them. It can also invite one to figure out what they are about and what they're designed for. -
Projects that are structure around layers and not use cases suck and companies that support layered projects tend to suck. Companies that focus on use cases tend to focus on business value and tend not to suck.
That's not very helpful advice. Layers are pretty abstract animals. They have elements of packaging, patterns and services. People attribute all kinds characteristics to layers.
It may be true (or not true) that focusing on layers has a tendency for failure. If you mean that layers should be abolished all together then this will lead to very poor code quality.
Not understanding layers may lead to rejecting them. It can also invite one to figure out what they are about and what they're designed for.
I agree, layers are absolutely important for code quality and readability. However I feel to quote James Coplien from his thesis of multi paradigm design:
"[...] experience has shown that program comprehensibility, intentionality, and maintenance cost all fundamentally relate to the question of being able to understand software abstractions.The idea is developed here in the thesis, but it is developed more as a question of partitioning than as a question of abstraction. That is because experience has also shown that abstraction, which might be defined as selective ignorance, can be a dangerous thing in complex systems." -
Architecture, or lack thereof, is not the problem. People are the problem - and the solution. (Andrew Clifford's comment above rings true.)
Let me propose a slight refocus of the problem:
"Functional, or Data decomposition makes it easy to drift away from the real world. Domain Driven Design and Behavioral Decomposition keeps the focus on modeling the problem space."
The problem noted in the article becomes evident when the team becomes disconnected from the problem domain. Architectures are built/grown/evolve in all cases.
The question is: do the decompositions still make sense and have a tie to the problem domain? If not, then it is a slippery slope... -
Or at best focused on a very small part of the whole system. It is not only about ignoring the whole business, but partitioning results in an ignorance of the rest of the world. There are a lot of examples of such architecture.
I'm trying to imagine a good counter to this ... an architecture that requires you to know the entire system to do anything? Separation of concerns is at the heart of design. Broad business knowledge is a good thing, but it's a human problem outside the architecture.
The OP was not about the software design, but the team design and "understanding of software users, their problems and concerns" When I worked on call center software all full-timers on the team were expected to spend a couple days a year sitting with a CSC on the phones and take turns introducing new releases to them.
But we also had tasks that we could give to "augmentors" from a pool with zero call center background. The pool folks were either in a good place getting to see lots of projects and parts of the business or in a bad place never getting to see enough of any of them to make sense. I'd guess they thought it was the latter. -
Sorry, I guess I don't understand what architecture has to do with ignorance...
Knowing about the business is needed to create a coherent solution, but each piece needs to be nicely designed to avoid spaghettis. I guess each developer needs to keep loosely coupled with others, but they must understand what the piece they are working on, means to all the stakeholders, including clients.
Now, architectural separation of concerns and boundaries of responsibilities are not to keep in obscurity and ignorance different parts of the teams, they are to keep the structure clean and reusable. One thing are the functional elements and another one are the engineers. Furthermore, having the the least engineer attending to client chats or looking at them afterwards, will help him/her to improve the design.
So, the answer may be: No, architecture has nothing to do with gaps of that kind; policies and methodologies may dictate those non-sense restrictions, but they are not, by any means, dictated by a functional structure.
William -
From my point of view, a good architecture will put the first priority in covering all aspects of functional and non functional requirements from the business need. It should simplify of all reusable components, put an abstraction level, hardly think about objects management againts the performance, using best practices of design pattern, etc.
I don't agree that would potentially create a gap if, there are good communications between architects and developers. They should have the same perspectives, commitment of quality, as well as skill development.
I believe if there is a good environment in projects communication management, there will be no gap but a good quality software. -
I'm trying to imagine a good counter to this ... an architecture that requires you to know the entire system to do anything? Separation of concerns is at the heart of design. Broad business knowledge is a good thing, but it's a human problem outside the architecture.
Think about, for instance, usability. Developers that do not know how GUI look like will potentially create bugs! Abstraction is good but it should not yield a total ignorance. Developers should be aware of how the system works, and not only how their component work. Usecases form good tool for partitioning the software into functional components that yet talk the functional logic of the business. The point here is architecture should not partition software into technical compoenents that take developers out of the context...
16 comments
Watch Thread Reply