*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Objections to designers handing off designs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Objections to designers handing off designs" Watch "Objections to designers handing off designs" New topic
Author

Objections to designers handing off designs

Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Originally posted by Dave Thomas: (in another thread)
(And of couse we also have a problem with designers handing designs to coders, but that's a seperate thread).

Dave, would you care to elaborate on this?
I've been trying to think of a good approach to try to change managers' minds about having analysts/designers do analysis and design, then have them hand their designs down to the programmers to do the "construction". I have never found this to work well if the programmers were not in on the analysis and design.
Any help in getting this message across would be great. Thanks.
Junilu

[This message has been edited by JUNILU LACAR (edited May 22, 2001).]


Junilu - [How to Ask Questions] [How to Answer Questions]
Dave Thomas
Author
Ranch Hand

Joined: May 01, 2001
Posts: 45
Well, we could come at this a couple of ways.
One is to think of the practicalities of the situation. Every time we introduce an interface, we have to devise some way of communicating across it. If you call one person a designer, and another a coder, then you have to invent some way for them to communicate. UML? Text documents? Hand waving? Whatever you choose, it's inefficient and error prone. It places an extra burden on the team. It slows down the process, and adds costs. And (more insidiously) it tells the "coders" that they aren;t responsible for the design. They get to invoke the Nuremburg defense: I was just following orders. And that just ain't healthy.
Then turn it around and look at it in terms of people. Does someone wake up one morning suddenly being able to design? Obviously not. But in some companies, this is the assumption: they annoint people designers, and expect those people to design.
For some software projects, there is the need for this kind of stratification. These are projects where the cost of failure is high enough to make the extra cost of communication bearable. These projects are rare, and typically involve something life-threatening.
For the rest of us, the most efficient form of communication is continuous interaction. We don't talk in documents, we talk. We don't draw maps, we point. We don't dictate, we lead by example. And all these things are best done by putting a group of developers together and letting them interact in good faith. You need ground rules, and you need structure, but you rarely need hierarchies. The best designers can still learn a lot from the most junior coder if they work with them.

Dave


Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
We had a similar problem in one of my earlier orgainizations.They had hired designers to work on designing the system.The result was the coders didn't take interest in applying themselves while coding.Also, there was lack of communication between designers and the coders.It was then decided that the coders should be kept in the loop while designing the system.
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited May 23, 2001).]


<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
Avijeet Dash
Ranch Hand

Joined: Jan 21, 2001
Posts: 148
As a coder I have felt, I can straight way code without looking at the sequence digram unless otherwise in doubt.
For me the Page spec/requirement is enough to decide the low level coding.
The problem i face is reading all these long documents so boring. I guess if the Documents and digrams could be made interesting (I don't know how) then probably the communication between designer and coder can be made smooth.
we read books, magazines what is wrong with a Design document with text and uml digrams?
sometimes the sequence digrams are not correct or updated and the design can get away saying its at a high-level.
the class names would be wrong, there will be assumptions about messaging.
when you write a code, it has to run. when do a design there is nothing that validates it. It always gets the benefit of being at a high-level. the designer finds doing so many obvious digrams boring and the coder find them not necessary.
I don't know what Dave/Andy has to say?
Dave Thomas
Author
Ranch Hand

Joined: May 01, 2001
Posts: 45
Originally posted by Avijeet Dash:
when you write a code, it has to run. when do a design there is nothing that validates it. It always gets the benefit of being at a high-level. the designer finds doing so many obvious digrams boring and the coder find them not necessary.

I think this is a key idea. If a design can't be validated, then you are running a risk. If you insist of having all the design done before coding, you're increasing that risk, as you are increasing the time that will elapse before you find the mistake.
The key is to find ways to express design in executable form, and aldo find ways of expressing executable code at a high level. That way there is only one artifact, the code, that does both jobs. To some extent this can be done by having higher-level languages and environments. I'm afraid that Java isn't high enough for this (although the decarative nature of EJB containers is a step inthe right direction). Also tools like Together can be useful at producing an overview from a bunch of code. However, even Together has a problem, in that it can't differentiate between the key concepts and the housekeeping details.
So while we're waiting for the perfect toolset, what can we do? Personally, I think we need to break down the artificial wall between designers and coders and accept that its a continuum. We need designers communicating their ideas by example: by writing code. That way the rest of the world will come to realize that they're not doing anything especially different or difficult. All they're doing is the same as we all do every day: abstracting and organizing.
Dave
Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Originally posted by Dave Thomas:
I think this is a key idea. If a design can't be validated, then you are running a risk. If you insist of having all the design done before coding, you're increasing that risk, as you are increasing the time that will elapse before you find the mistake.
The key is to find ways to express design in executable form, and aldo find ways of expressing executable code at a high level. That way there is only one artifact, the code, that does both jobs...
Dave

Dave, here's a question to you (it came up first yesterday when I was leafing thru Beck's XP Explained) regarding "If you insist of having all the design done before coding, you're increasing that risk..". I am liberally interpreting your "all" as "most" here... so my question is: When to begin the process of coding?
Fowler's article, Is Design Dead?, talks briefly about the similarities and dissimilarities between design in building construction and design in software: that you need design in both to proceed but probably less upfront design in software. But how do you decide what you have designed is enough to proceed? It seems like, in XP, people just start and then (hope that they ) arrive at GoF like patterns before the project is delivered, right?
There's a catch-22 here... To have that kind of a foresight one has to be experienced and be a consummate designer in the first place, so that you don't have to come back to start from scratch. But you can't probably be so good in designing until you have done upfront designing for a long time!
Sanjeev
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Originally posted by Sanjeev Arya:
But how do you decide what you have designed is enough to proceed? It seems like, in XP, people just start and then (hope that they ) arrive at GoF like patterns before the project is delivered, right?
There's a catch-22 here... To have that kind of a foresight one has to be experienced and be a consummate designer in the first place, so that you don't have to come back to start from scratch. But you can't probably be so good in designing until you have done upfront designing for a long time!

In XP, coding doesn't "just start". I think a common misconception about XP is that design is thrown out the window and people just start hacking away. No, XP spreads the design activities throughout the entire process, mainly through Refactoring and creating Tests.
In Refactoring/XP, you will find a lot of references to "listening to what the code is telling you" and "code smells". Yes, it does take experience to know what the bad smells are and listening to what the code is saying. But you won't gain that experience by doing BUFD (Big Up-front Design).
I guess what I'm trying to say is that there is a point at which you know enough about what you need to do such that you can start writing code to see if the design you have in mind (or on paper) actually works. Experience will help you know when you have gotten to that point. If you get stuck in design, then try to get out of the rut by writing some code.
That's why an iterative development process is better: analyze a little, design a little, code a little, test, repeat. That way, if you make mistakes, they are little mistakes and you can pinpoint exactly where you went wrong. If you do things at one go, you end up with a lot of mistakes and it will take you a lot longer to figure out the causal relationships. That makes learning a lot harder and longer.
Junilu

[This message has been edited by JUNILU LACAR (edited May 24, 2001).]
Dave Thomas
Author
Ranch Hand

Joined: May 01, 2001
Posts: 45
Just to follow up slightly on this, another aspect of XP is that they strive hard to have less design. They design throughout the coding process, but also work hard to produce only what's required.
In a pure XP project, you'd start of implementing some task by writing a test that failed. Everything else would follow from there. Upfront design skills are replaced by the ability to write small chunks of code, and then refactor these chunks in their wider environment. It's a different skill, and it relies on having additional practices in place as safety nets (things like pair programming to give you continuous peer review, system-wide unit tests as insurance, and short iterations to limit damage).
When I code, I work from an architecture, but typically discover what is conventionally called the design as I go along.
Dave
Andy Hunt
Author
Ranch Hand

Joined: May 01, 2001
Posts: 54
On the subject of designers vs. coders: a metaphor ocurred to me last night that might be useful (it may also be a complete waste of bandwidth, you never know :-)
In a racing car, a family car, even a big tractor-trailer, the guy who is steering also works the gear shift, gas and brakes. I see this as being analogous to the small, medium and large size teams where design and coding are handled by essentially the same group of people; you don't have a separation of coders and designers. In these contexts, the immediacy of response time and integration of sterring/gear shifting/etc. is key.
On an oil tanker, or other large ship, the situation may be quite different. The captain issues the orders, someone else steers, and the folks down in the engine room make it go faster or slower, or slam on the brakes. Five or ten miles later the thing stops :-)
If your project is the size of an "oil tanker", then the separation of responsibilties might make sense. In anything from a race car to a tractor-trailer, it's suicide.
At least, that's how I view it.
/\ndy


/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Originally posted by JUNILU LACAR:
...
That's why an iterative development process is better: analyze a little, design a little, code a little, test, repeat. That way, if you make mistakes, they are little mistakes and you can pinpoint exactly where you went wrong. If you do things at one go, you end up with a lot of mistakes and it will take you a lot longer to figure out the causal relationships. That makes learning a lot harder and longer.
Junilu

[This message has been edited by JUNILU LACAR (edited May 24, 2001).]

Junilu, let me rephrase, when do you start a big, huge project? Say, a 50 member 2-year project. You better do BUFD then, right? Even if you don't label it BUFD you'd finally end up spending a lot of time just trying to be able to start coding.
XP makes perfect sense for smaller projects. So why this new term "XP" in the first place, when all we are talking about is the "degree" of design to do upfront. Beck mentions that UML diagrams also are not a no-no in XP, so people can if they want to make class diagrams in XP too. That was reassuring since XP process appeals to me and UML diagrams also seem to be natural.
GoF patterns, Refactoring patterns all are mighty useful in XP. So what else is different in XP (I need to read the Beck book now )? The biggest appeal of XP seems to be is that it is inherently natural, just like Refactoring. This is what I would "naturally" do (in the absence of bosses ). I would love to hear about XP success stories in large projects.
Maybe I should put this in the XP forum... or maybe our friendly Sheriffs will reorganize and put XP and other "processes" in this forum, Refactoring and XP are too tightly coupled .
Sanjeev
Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Originally posted by Dave Thomas:
Just to follow up slightly on this, another aspect of XP is that they strive hard to have less design. They design throughout the coding process, but also work hard to produce only what's required.
In a pure XP project, you'd start of implementing some task by writing a test that failed. Everything else would follow from there. Upfront design skills are replaced by the ability to write small chunks of code, and then refactor these chunks in their wider environment. It's a different skill, and it relies on having additional practices in place as safety nets (things like pair programming to give you continuous peer review, system-wide unit tests as insurance, and short iterations to limit damage).
When I code, I work from an architecture, but typically discover what is conventionally called the design as I go along.
Dave


Sorry I didn't read this post before replying earlier (to Junilu I suppose). Its clearer now how XPers would start a project.
Also it seems the knowledge of patterns comes handy in XP at a later stage mostly, when refactoring. Less pattern-based designing at the beginning, right? More like trying to go up in a balloon over the code already written and find if any patterns show up. That seems very logical in time-pressed situations.
Sanjeev
Dave Thomas
Author
Ranch Hand

Joined: May 01, 2001
Posts: 45
In fact, many XP folks would say you don't refactor into patterns, but refactor as required. If that happens to end up in a recognized pattern, then that's fine, but it isn't a target.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Originally posted by Sanjeev Arya:
Junilu, let me rephrase, when do you start a big, huge project? Say, a 50 member 2-year project. You better do BUFD then, right? Even if you don't label it BUFD you'd finally end up spending a lot of time just trying to be able to start coding.

From what I have read about XP, the optimal team size would be less than 15, maybe even fewer. There are other agile methodologies that are supposed to scale better to large teams although I think if you could break up a big project into smaller teams, you could still do XP.
My personal thoughts about BUFD and UML: You can write just as crappy software without the pretty pictures. The trouble with most shops that choose to adopt UML is that they end up focusing more on producing "correct" models, getting the notations right, which way the arrows go, etc.
If instead of getting hung up on drawing correct models for the whole system, customers and developers spent more time communicating face-to-face, identifying and setting priorities for the next few iterations, and focusing on things that are of more immediate value, then developers would be able to get down to business a lot sooner and start giving the customer value for their money in the form of working code.
Junilu
Sanjeev Arya
Ranch Hand

Joined: Feb 13, 2001
Posts: 58
Originally posted by JUNILU LACAR:

My personal thoughts about BUFD and UML: You can write just as crappy software without the pretty pictures. The trouble with most shops that choose to adopt UML is that they end up focusing more on producing "correct" models, getting the notations right, which way the arrows go, etc.
If instead of getting hung up on drawing correct models for the whole system, customers and developers spent more time communicating face-to-face, identifying and setting priorities for the next few iterations, and focusing on things that are of more immediate value, then developers would be able to get down to business a lot sooner and start giving the customer value for their money in the form of working code.
Junilu


Well said. Makes sense.
I absolutely liked the idea from Andy (or Dave?) of using simple whiteboards and digital cameras to quickly capture system diagrams. That seems to be the essence, not to miss the forest for the trees (or is it the other way round , whatever).
The best thing about patterns and UML is a wider (and more or less standardized) vocabulary. You talk about face-2-face communication... Its precisely this sort of thing that Patterns and UML improve so that 10 persons on a team do not interpret 10 different things from a fuzzy problem/requirements statement (mostly in English ).
So, a design overkill is what XP addresses I guess. Hey, nobody listens when you say "don't overdesign". Everybody listens when you say "do XP" and XP says "don't overdesign". Funny, eh!
Sanjeev
Andy Hunt
Author
Ranch Hand

Joined: May 01, 2001
Posts: 54
Originally posted by JUNILU LACAR:

If instead of getting hung up on drawing correct models for the whole system, customers and developers spent more time communicating face-to-face, identifying and setting priorities for the next few iterations, and focusing on things that are of more immediate value, then developers would be able to get down to business a lot sooner and start giving the customer value for their money in the form of working code.
Junilu

Here here! That's what its all about. A lot of people mistakenly say that XP is anti-documentation; that's not true. Every artifact has its cost. Once the customer realizes the true cost of a pretty picture (and realizes that they can't ship *that* to the client), then the pretty picture goes bye-bye. If, on the other hand, the picture has some business value, and they understand the costs involved and still want it, then that's fine too. Draw away.
But at least they get a choice as to how to spend their money :-)
/\ndy
Daniel Dunleavy
Ranch Hand

Joined: Mar 13, 2001
Posts: 276
Hi everyone. I haven't visited this forum before.
A few points I would like to make from someone who has worked both sides of the track (design and programming)
First...its all about TEAM. You cannot have a designer just hand off a design and move on to the next system. Its an iterative process. And the designer should remain involved with the project until its completion. It no longer occupies 100% of his time, but it shouldn't be 0% either.
Second thing, which goes along with the TEAM concept, is that you should get signoff of the design from the key players in the project. You don't need every developer in the room, but you shouldn't be working in a vacuum. Although not every feature might be looked at, the major more complicated features should be. Recently a project I was involved with included an inventory and a scheduling system. We agreed that the inventory didn't need as much involvement from everyone, but the complicated scheduling piece definitely needed to be. The designer doesn't have all the good ideas. Each can contribute, agree to, and sign off on the project.
When I worked for large corporations who had a little more time and money, we used to be able to prototype before moving into full development. This could find holes in the design before you went too far down the wrong road.
I think there should be better specs given to the programmers than I have seen at web companies. It allows someone with less experience do a better job. With just a model diagram in front of him, he will need more supervision which ties up another resource.
It seems like everything works well in moderation. Like teams of 5 people work really great. When you get to 20 and over there is more chance of problems. Either someone thinks someone else is handling 'it', or he's creating something know one will ever no how it works.
Just a few thoughts
Dan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Objections to designers handing off designs