The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Is Agile compatible with de-coupled design/development

Until recently the developer group was responsible for both architecture and design of the application(s) they built. For the most part it worked that the lead developer or manager of the group reviewed the user stories and feature requests and worked up a wireframe of what was needed and the developers themselves were primarily responsible for arriving at a workable architecture that was agreeable to the group, designing the software and then building it.

It seemed to be working well. Under our Agile(SCRUM) methodology we were releasing software that was meeting the needs of the users fairly regularly until a change in upper management. The new manager insisted that Requirements and design should not be done by the developer group at all, and formed another group to define the System requirements and designs and hand them off to the developer group to "code them up".

I am struggling with how to make this work under Agile where designs are supposed to be emergent and a high level of interaction between stakeholders and the team is necessary. I have talked with the guy who set this up and he talks up the fact that he is completely on board with Agile, but in the same breath says he doesn't think it necessary for the programmers to talk to stakeholders at all. He uses as an argument that outsourcing companies can take designs and work on them without input on the designs so we should be able to work like that.

(1) Am I right that pulling the design/architecture this far away from the developers is going to undermine an Agile development approach?
(2) Am I right that the developers are going to lose interest and jump ship if they aren't allowed input on the architecture or designs of the software they are building?
(3) Can anyone recommend a tall structure that would be fatal to jump off of?
Anon Send private email
Wednesday, July 16, 2008
 
 
You are correct.  Software is sufficiently complicated that trying to artificially separate "Design" and "Implementation" is doomed to failure.  "Failure" here meaning extending schedules, and implementing software that doesn't meet the user's needs.

That's one of the key aspects of Agile development, was recognizing this and taking steps to reconnect design and implementation.  Your new manager sounds like an idiot to insist on changing something that was working well.

My favorite "Jumping off" point was the Panther Hollow Bridge in Pittsburgh PA, next to Carnegie-Mellon University.  Say hi to the failing Architecture students when you go.
AllanL5
Wednesday, July 16, 2008
 
 
(1) Am I right that pulling the design/architecture this far away from the developers is going to undermine an Agile development approach?

I don't believe so. I'm confident of this because I use an agile approach, but I still maintain clearly separated architecture and development processes. I don't mix them, even if the people involved is the same because i don't want to mix architectural (strategic) decisions with implementation (tactical decision). 

You can still maintain a close relationship between the design and development team. Your problem is that now you have three stages in the feedback loop (user<->design<->development). 

(2) Am I right that the developers are going to lose interest and jump ship if they aren't allowed input on the architecture or designs of the software they are building?

That's is for me THE issue. Even if you manage to make the agile methodologies work under the new organization, people will be affected. My advice: concentrate on people, not the methodology.

(3) Can anyone recommend a tall structure that would be fatal to jump off of?

Collserolla communications tower here in Barcelona
http://www.torredecollserola.com/

I don't think you needed it, but any excuse is good to visit Barcelona.
Pablo Send private email
Wednesday, July 16, 2008
 
 
Thanks for the input. Do either of you have any references or links that either argue the case for keeping the design within the same department as the developers or alternately give some advice on how to make it work split out?
Anon Send private email
Wednesday, July 16, 2008
 
 
> ... Requirements and design should not be done by the developer group ...

I think it would be more usual to 'outsource' the *requirements* (to a product management group for example), but to keep the [software] *design* in the software developer group.

> Do either of you have any references or links ...

There's http://users.rcn.com/jcoplien/Patterns/Process/section16.html

I haven't read it but Coplien's patterns (he was at Bell Labs) have been published as a book, http://www.amazon.com/Organizational-Patterns-Agile-Software-Development/dp/0131467409 which might be what you want
Christopher Wells Send private email
Wednesday, July 16, 2008
 
 
Make your new BAs attend the daily scrum meetings.  Since they're a pig (and not a chicken), they need to attend and participate.

http://en.wikipedia.org/wiki/Scrum_(development)

Just because they're in a different department within the organization doesn't mean that so far as working on the product they can't have a close relationship with the other team members.
xampl
Thursday, July 17, 2008
 
 
Christopher

Interestingly, for the problem Anon has, this same approach as described in the "Architect Also Implements" pattern, is also proposed by RUP

Concretely, RUP proposes implementing the core architecture early in the development process before you start implementing most functional features.

"In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending
on the scope, size, risk, and novelty of the project. This effort should at least address the critical use cases identified in the inception phase, which typically expose the major technical risks of the project"

Rational Unified Process: Best practices for software development teams
http://www.ibm.com/developerworks/rational/library/253.html
Pablo Send private email
Friday, July 18, 2008
 
 
Hey, I'm pretty sure you could get Agile to work without unit tests, or user stories, or whatever. It's probably a lot harder but, more importantly, why would you want to?

I'd be interested in hearing from your new manager what particular advantage he feels is gained by separating design and development?
Bruce
Friday, July 18, 2008
 
 
"I'd be interested in hearing from your new manager what particular advantage he feels is gained by separating design and development? "

Well Bruce, he has been pretty dodgy on that point. Mostly he says it is a gut feel and he can't explain why his gut is telling him it will work better than the structure I propose based on my experience in development shops and his lack thereof. Generally, he is somewhat hostile to asking questions about any of his decisions and sees it as a challenge to his authority. The only time I was able to pin him down to make a concretes statement he said (paraphrasing) "That would require developers to have to understand the [problem domain] and that is not their job, they should take a specific set of functionality points and implement them without slowing down the process by asking the stakeholders or BA's questions about the architecture or design. If we give them too much input, they will just mess it up because they don't and can't understand our business model."
Anon Send private email
Friday, July 18, 2008
 
 
Woah.

I mean, really. Woah.

First, I guess this is a really good reminder that our field is so broad as to allow so widely divergent experiences. Your managers world view of software development is so far from my own that I can barely relate. Interesting.

But, that's not helping you any.

What COULD help you is this:

1. His main concern seems to be optimizing the rate of output. He believes that separating design and implementation will do this. You could hit him with a Theory of Constraints demonstration.

You now essentially have a two step process where you had one before. Hey, a new constraint! What happens if the rate at which design is produced is less than the rate at which developers can turn this into code? Or vice versa? On one hand you'll have idle developers. On the other, design "inventory", which is waste in the worst sort of way.

2. What's the thinking on testers? Are they supposed to operate without domain knowledge as well?

If the answer to that is "yes", then I guess you don't really need testers. The developers can do it all.

If the answer to that is "no", then you have a strange situation where the front and back ends of the process have domain knowledge but the middle doesn't.

3. I just had a thought. Are the BA's providing the tests for the "stories" as well? Since they're the only ones with domain knowledge, they kinda have to provide the tests as well.


Good luck. I wish I could say that it will all work out well but it seems like the best you can hope for is that this new arrangement will fail spectacularly and early.
Bruce
Friday, July 18, 2008
 
 
Thanks again Bruce. I was not familiar with the Theory of Constraints, that might be helpful.

To answer your question, the BA's are not providing tests. The requirements are supposed to be the input to that process. Under my old model the testers were attending the weekly stakeholder demo's, but I don't know how it will work in the new regime.
Anon Send private email
Friday, July 18, 2008
 
 
It's funny that the manager should mention outsourcing, because at first glance it sounds like he's trying to "modularize" "coding" so he can just do the requirements in-house, and swap out the coders with an outsourced team. Is there an undertaker following you around the office, measuring you for a coffin?
(User deleted) Send private email
Friday, July 18, 2008
 
 
Your boss wants to separate functionality from technical implementation, which is a great idea (and part of scrum), but because he is abusing technical terminology, he is going to end up pissing in your kitchen.

Design = what the code does (domain experts)

Architecture and technical specifications = the structure of the code (code experts)

Jeez.
PeterR
Monday, July 21, 2008
 
 
The design is the code.

I don't write my programs in Microsoft Word.
arf!
Tuesday, July 22, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz