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.

How can I make functionality more visible?

I work with a medium sized team of ~30 software engineers and I find that often people (perhaps even myself) are creating duplicate functionality. For example, there may be multiple Singleton classes, Logging Classes, duplicate Data handling classes, etc...

How do you prevent multiple copies of classes from being created - or how do you enlighten people to the existence of the functionality they seek?

I was thinking of using Doxygen but I'm not sure how easy it is to translate people's need (search string), such as, "I need to make sure only one of this class instances exist" to a link to the Singleton web page (that is a simple example).

I could do a wiki entry that people update to educate others to the functionalities existence, however, many people sometimes lack the time/motivation to keep these up to date.

Do you deal with this or let it slide? 

Any suggestions?

Thanks,
Lyndsey
Friday, October 20, 2006
 
 
pair programming to spread knowledge?
stand-up meetings so people know what everyone else is doing?
code-reviews?
G Jones
Friday, October 20, 2006
 
 
First of all you need everyone on the team on board with reducing duplication.  Without that, nothing is going to happen.  When people are actively trying to find an existing class before they create a new one, then stand-ups, wikis, etc. are tools they will use.
Mike S. Send private email
Friday, October 20, 2006
 
 
The answer might be to have some architecture.

For example you might have a GUI component and a Data component. The GUI team won't duplicate functionality that exists in the Data component, because they know that if it's Data-related then they shoul be invoking a Data API instead of coding a new Data-handling class. By separating the system into components:

* People know when they should invoke another component instead of coding their own class (which avoids duplicating functionality across components)

* People (e.g. the Data team) only need to know what classes exist within their own component (e.g. the Data component; they don't need to know internals of the GUI component at all) in order to avoid duplicating functionality within a component.

Plus, you might have a low-level utility/library (which includes Logging, threading, timers, debugging, maybe configuration, maybe sockets) which implements things used by every component).
Christopher Wells Send private email
Friday, October 20, 2006
 
 
> Do you deal with this

Yes, daily. I do a sanity check code review of all the previous day's check-ins.

> or let it slide?

No. I would consider these "broken windows" which need to be fixed. (http://www.pragmaticprogrammer.com/ppbook/extracts/no_broken_windows.html)

As already mentioned, this first requires a culture which values code reuse and no duplication. If everyone's not on-board with this as a basic requirement for their code, then it's going to be an uphill battle.

Once that's in place, you need a code librarian/architech who knows the systems well and can review all check-ins to verify the existing code base is properly used. Non-use/duplication of library code gets ruthlessly changed to use the common code base. They can also see duplicated code which isn't in the library and refactor as appropriate. They need to have both the maturity and clout to be able to make and enforce *good* decisions.
Harley Pebley Send private email
Friday, October 20, 2006
 
 
Talk?
son of parnas
Saturday, October 21, 2006
 
 
Thank you everyone, I will be exploring all of the options you sugggested.

Someone suggested the solution being "talk" which seemed a little glib.  What does that mean? Every time functionality is added that one should stand up and announce that? Or email it?  That becomes noise which people will tune out.

People's suggestions of a system of monitoring combined with a culture change as well as at-hand documentation seem worth pursuing.

Thank you again.
Lyndsey
Monday, October 23, 2006
 
 
Code reviews are your best friend.
not an ms access guru
Tuesday, October 24, 2006
 
 
Definitely, review daily check-ins.

Talk? Sounds like you need more communication on the team.

My very simple approach is getting the programmers around a whiteboard for an hour week. Go in with a folder of the code check-ins for the week so they see you are reviewing it, and measure the time for round table for everyone's activity. When a programmer starts speaking about what he's building he invariably grabs that marker and starts drawing lines.

I have found that some members of a team can only relate (or will actually pay attention...) when there were boxes and circles and lines and scribbles all over a whiteboard describing the work at hand. Perhaps it has something to do with auditory vs visual people, I'm no psychologist, but it's the best way I have found to get the most from the team's diversity.

When Quiet Joe who never speaks in meetings feels compelled to grab that marker and illustrate how his work has been duplicated by Loud Mike, you have communication. Mike's code may benefit from Joe's input, and it helps reduce the chance for duplication of effort in the future. I especially enjoy it when they are wrestling each other for the marker, you get good stuff happening then! :)

Have an agenda, and steer the discussion. It is easy to go off target. As tedious as it sounds, there needs to be some minutes taken and most critically - actions to be taken after the meeting. The actions of the previous meeting need to be *quickly* reviewd at the start of the meeting.

If nothing is done with the fruit of the discussion, people will very quickly feel the meetings are 'useless' and they will be less inclined to participate.

Structured, but not too structured. ABSOLUTELY invite ONLY programmers - no sales/accounting/misc people, only actual coders.

Use humor and get them hopped up on coffee and free donuts.
Jason Thibodeau
Wednesday, November 15, 2006
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz