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.

Need a Software Design Methodology

The aim of this question is to produce the longest thread yet found on JOS. :-)

But seriously:

I am on a mission to find the best workable software design methodology for a small team doing web application development. The reason: we have all but abandoned the design phase of the development lifecycle. So, I have been trying to figure out or discover an appropriate software design methodology that is (1) easy, (2) painless, and (3) concise. Our current methodology was pushed onto us by the former lead contracting company, which is a large Defense contractor. This methodology consists of nothing more than producing a document that describes—using words and nothing else—the technical details of the software we have to build.

Aside from being a largely worthless document as well as being no methodology at all, the software design document is also (1) difficult to write, (2) painful to create, and (3) tends to be verbose. As a result, there exists on my team a general distaste for the design phase of the software life cycle in general, and for creating design documentation in particular. It comes as no surprise, then, that the whole design phase goes largely overlooked by the development team whenever possible.

I am familiar with a number of design methodologies, so please, no bits of advice to read This Book or That One. I want to know from you all what has worked on your team...and what hasn't.

Chris Send private email
Sunday, January 16, 2005
Well Chris, I gather there is no software design methodology where you work because the leadership of your software company finds more value in just 'getting things done' rather than 'getting things done right'  :)  Which can work in the short term, but begins to rear it's ugly head in the long run.

Guess the question is - are your software engineers hackers or are they professionals who work together in a cohesive manner where everyone has buy in into doing things properly?

If not, find the cancer in your group and get rid of it - it might hurt at first, but you'll be better off in the long run.

Again though, if your management refuses to listen it could be a painful process.  A good project manager would help.

Good post Mr. A

Your friend,

Sunday, January 16, 2005
Let me add. Your team might want to write these documents, but when your boss gives you one week to code a one month project, guess what tends to be thrown out the window first?

Sunday, January 16, 2005
Thanks, Steve. I should have known you'd be haunting these forums. > Sigh <

Oh well.

You know as well as I do that we have some real hacks on our team; but, we also have some (potentially) good young developers. You of course are in a class by yourself...but in a good way. :-)

True, our management doesn't value the importance of a design phase, but how many organizations do? That's why I'm interested in finding out whether anyone has made use of a design methodology that is concise and gets the job done. Somebody has to have something that works. After all, we can't be the only development team in this pickle.
Chris Send private email
Sunday, January 16, 2005
Well, we both know what causes the process to fail - you are right, we have good people, but it only takes one lone wolf to buck the system.  Management and the team see this, they think he is responsive, but the rest of us know he is off hacking the system  :)  They then see us as being slow, even though our designs are much better and create better quality software.

With that out of the way, it takes concerted effort to educate the customer on the need for it. 

some ideas:

1. when the customer asks for an estimate, make sure the estimate contains design time in it.
2. have peer reviews

3. have sign off on design documentation prior to allowing coding to occur.

4. create a design template for the developers to use, that is not overly complex and discouraging to use.  Then it becomes a painful thing vs a 'good' thing.  If they see it as a good thing, it will be promoted.

maybe that could mean a tool like visio


I know you want to hear from others here, but seriously, we both know that one person on the team refuses to play with others, changes our code constantly without design specs, etc... He is a cancer on the team.

Everyone else expresses interest in design.  Time for a culture change, I think in this case it needs to come from the inside out vs the outside in (the dev team needs to push it instead of relying on the management team).

Time to talk to the boss about this guy  :)
Sunday, January 16, 2005
Anyone else around to help us out :)

Thanks Chris, good idea to bring this here
Sunday, January 16, 2005
I would use scrum for project management. Some of XP for the programming practices.
son of parnas
Sunday, January 16, 2005
Thanks! That looks good so far in some quick reading - I'll read more.

We really need to find something to help our team - we have a  great customer base, the project just grew so much faster than the team expected.  Its evolving, but most of it is just  tons and tons of vbscript asp pages with no objects, etc... a nightmare to manage.

Now we are working on upgrading to .net (more like rewriting)
Sunday, January 16, 2005
tough part is we have senior developer who has learned basic asp 4 years ago and thinks the best approach to everything can be hacked in 5 minutes.  think spaghetti code x 10.

he works like 80 hours a week and changes code behind our backs and muddles with the code on weekends.

he doesn't understand design nor does he follow any best practices.

on top of that, he has access to all our servers and has been caught actively on the production database changing records.

One day he managed to 'accidently' delete our entire user table and we had to restore it.

management likes him cause he is 'responsive' to their needs.  he will do anything to help them to look good.  which 90% of the time means a quick, unthought out solution.

he then holds his value by being the only one to understand how he concocted such a solution.

it's been a nightmare that causes the other developers to not trust him.

now. knowing this - I'm not sure any methodology will work?
Sunday, January 16, 2005
From what I can tell, you have at least some experienced developers on your team and you are educated, if not experienced as well, in software project management. Given this and what I can read on this forum, I'd say you have a people management problem. These problems can't be addressed with software design methodologies. You know what your problem is, you need to attack it head on.
Stefan Batres Send private email
Sunday, January 16, 2005
Sounds like Rasputin. Suck up to the boss and did  things to look good at everyone elses expense. Got killed off by MI6.
Try that for a solution.
Sunday, January 16, 2005

Web Development SDLC - From Failure to FLiP (If you're interested in reading my long-winded article about my team transitioning to FLiP.)
michael sica Send private email
Sunday, January 16, 2005
Right. Steve has addressed a very real problem on our team--we have a rogue developer who believes he is invincible. But, we are taking steps to eliminate him. Enough said.

If I may be so bold, may we return to discussing a software design methodology that works well for small teams: easy, painless and concise?

I'll chack out scrum. Steve, you and I can compare notes Tuesday.

Thanks everyone. More thoughts, please.
Chris Send private email
Sunday, January 16, 2005

I read your article on FLiP. Seems like a good methodology based on the Prototyping Model for a software development life cycle. Have you maintained good results using this model?
Chris Send private email
Sunday, January 16, 2005
Alistair Cockburn reports that he found something interesting when he started interviewing project teams: a lot of teams were very apologetic about the fact that they didn't do the things that a team "should" do.  (Keeping design docs up to date, doing all diagrams in UML etc.)  Over and over, he saw successful teams apologise for skipping supposedly important tasks, and he eventually realised that the success of those teams showed that the neglected tasks weren't so important afterall.

You mentioned that your team has a general distaste for the design phase.  I can't tell from your description, but I wonder if they merely have a  distaste for what they think a design phase "should" be.  Perhaps they are actually quite comfortable with doing design (in the sense of engaging their brains well before coding), and are merely uncomfortable with process elements which they percieve to be low-value.

I think the industry under estimates the differences between small teams and large ones.  Much of the literature focuses on the needs of medium and large teams. So when small teams evolve successful, lightweight approaches, they can mistakenly feel "guilty" about not following the heavier processes that have been described for larger teams.

Steve McConnell wrote an article here - - on differences between small and large teams.

Alistair Cockburn's results are summarised here:
John Rusk Send private email
Monday, January 17, 2005
Agree with John Rusk.
Alistair Cockburn also says that there is no perfect methodology for every situation. Teams have to work out their own set of conventions for each project. These set of conventions will depend on the type of people in the team: very communicative, not very communicative, very experienced, not that experienced, on their personal preferences, previous successful, not successful experiences, etc. People in the teams will re-evaluate and correct their conventions whenever needed.
You can adopt any methodology that the majority of developers in your team feel comfortable with, and is producing the right results. It shouldn’t necessarily come from a book. You can create your own from tips from people in this forum. You should also adjust your practices to take advantage of the strengths of the members of your team.
Cecilia Loureiro Send private email
Monday, January 17, 2005
John: thanks for those articles. Cockburn's comments sum up why I don't like making low level design documents unless absolutely necessary: more information is transferred by simply asking someone and things are often very fluid at this level.

Not that I don't do documentation: I believe in writing high level Architecture documents/UML diagrams/theory of operation and keeping them up to date. This is a simple way of introducing a new/replacement person to the codebase's structure. But low level design documentation we usually avoid unless it's something like a state diagram for a difficult to follow state machine.

IOW: don't write the docs unless they serve a purpose other than simply fulfilling a checkoff list.
lw Send private email
Monday, January 17, 2005

Yes, we've had a lot of success with that SDLC. But you have to keep one thing in mind. If you don't follow the lifecycle you put in place, it won't work.

Every time my team has not followed what we have in our SDLC, it's bitten us in the a$$. So we quickly learned that we need  to stick to it!

Remember this too: Every type of project is different. We've had great success with this SDLC in the environment of a web team working in the IT department of a 6-7,000 person company. Your results may vary.
michael sica Send private email
Monday, January 17, 2005
>... to find the best....
That word "best" is the roadblock. You are looking for a silver bullet. There aren't any. There never will be any.

I'm going to recommend reading what the other guys have mentioned, and 2 more books:

The second link, is a helpful book by Steve McConnell. The latter part describes all sorts of methodologies. Pick what works, and use it.

I remember a presentation by one of the founders of scrum. They deliberately chose a noxious sounding name, because anytime there was a new methodology, every one used the name, just to become buzzword compliant (for a sample, look at all the folks misusing "agile").
Monday, January 17, 2005
Thanks everyone, for your comments. I'll be spending some time (along with Steve) looking at the different links you all have provided.

The trouble on our team is two-fold. First, many of our developers associate the design phase with the rather onerous document which functions as the end deliverable--the Software Design Document. That shouldn't be so. The design document--whatever its length and format--ought to aid the developer(s) in creating the software.

The second problem is that there is a tendency on the part of most of our developers to take the functional specifications and just begin hacking the solution. That's not good either, since it skips over any design phase. I would like to see us adopt a simple software design methodology that is detailed enough to aid the developer, but not so much so that it becomes an impediment to the development process.

By the same token, though, I don't want to become beholden to this or that design methodology, because they tend to have longish learning curves. Instead, I would love to use something that is (as I've said) simple, flexible, and--dare I say it?--even fun. But above all, it should be effective in aiding the developer.

Please continue to contribute to this thread. I think we have some great suggestions here, which can benefit more than just myself.
Chris Send private email
Monday, January 17, 2005

Following up on your first link, I discovered it refers to the book, "Death March, second edition."

I read the first edition some years back. Horribly depressing. Reading it darn near convinced me to look for a completely new career.

I'm glad I didn't. For all of the frustrations in the IT field, it is still possible to find a job in it and love what you're doing. Not many professions can boast that.

I'll be taking a closer look at the Rapid Development book you recommended, though. :-)
Chris Send private email
Monday, January 17, 2005
To hold your lone wolf manager in check what you do is implement source control, and work it out among the team so every file is always checked out except during builds ;)

Okay, so it might not be practical, but it could be fun for a short time :)
Joel Coehoorn
Tuesday, January 18, 2005
Ask yourself the following questions..

1. Do you hold on to the philosophy that design agreed upon is set in stone or do you allow design to evolve as you develop the product?

2. Do you have active customer input at every stage of the development or are you trying to duplicate the functionality of the previous piece of software?

3. How experienced is your team? Do you trust your team to make a good judgement everytime or do you feel the need to have it mandated/confirmed?

Your design methodology will depend on these answers.. If you allow the design to evolve with active customer feedback and with a experienced team, then any of the agile methodology is worth looking at. But it kinda requires all three. Even if one is not there, you might want to look at something like a iterative waterfall...
Vaidhy Send private email
Tuesday, January 18, 2005
My two cents -- a good methodology can be drawn on a single sheet of A4 and pinned to everyone's wall. It tells you exactly who bears resopnsibility for what, and by when.
David Aldridge Send private email
Tuesday, January 18, 2005

You ask some good questions...worth considering. Speaking to the first (is the design agreed upon set in stone, or do we allow it to evolve), we would LOVE to set the design in stone and allow for no scope creep. But, this is neither realistic, nor is it the case. As we meet with the customer at intervals during the requirements, design, and development phases, we always field requests for more. Usually, our customers are reasonable about their requests, and they listen to us when we say, "Yes, we can incorporate that change," or, "No, that will have to wait until version 2." Still, managing customer expectations must always be done with tact as well as a firm idea of which objectives are worth fighting for.

I think this addressed your second question, too.

As to your third question, our team varies in experience and degrees of proficiency. All of the team members are very bright.

We have been developing for the last several years using the spiral development model for expanding the capability of our current software. New software development is accomplished using the incremental or phased development model. These seem to work very well.

Our trouble, as I have alluded to, is the tendency to hack the solution instead of design it.

Frustrating, it is.

Thanks for your thoughts!
Chris Send private email
Tuesday, January 18, 2005
David, can you describe more about your idea of putting the design on a single sheet of A4 paper, as you put it? If a design can be represented in this way and still be effective, I would love to pursue that further.

Chris Send private email
Tuesday, January 18, 2005
I don't want to speak for David, but as I understand it, the single sheet doesn't contain the design, but the design process. That is, the series of activities that will be undertaken to achieve the final product. On it, you can also illustrate the outputs from each activity, and how they feed into other activities.
Ian H Send private email
Tuesday, January 18, 2005
I whole heartedly agree with the "Rapid Development" suggestion. It follows the no silver bullet philosophy (which I subscribe to at the moment) and thus gives you 800 pages of good ideas of what you can do to improve your team. Some are better than others, some are mutually exclusive, but in any case it offers you the ability to choose what you like and make your own methodology, that works for your team.
Peter Monsson Send private email
Tuesday, January 18, 2005
Thanks, everyone. You've given me some good things to investigate.
Chris Send private email
Wednesday, January 19, 2005
Scrum and other agile processes are definitely worth your time to check out.

Sounds, though, that your problem is almost more political than methodological. The lack of good estimation is project management, not design. The cowboy off in the wilderness making things safe for all the children is an even worse problem. There is no way of talkign to these guys and even fewer ways to get their disruptive influence seen by management. (I'll stop now or end up ranting for pages...) Both of these issues are political -- or managerial if you will.

I think finding a better design method will certainly be useful since your current one is so onerous, but it won't solve these other issues.

Best of luck!
Jeff Kotula Send private email
Wednesday, January 19, 2005
No matter what dev methodology you decide to employ (SCRUM is a good choice) treat it as a guideline rather than a rigid process.
Thursday, January 20, 2005
Most of the software companies I worked with so far, or most of the teams didn't really have a well-defined design process or even strong project management. Interestingly enough they were all looking for the magic tool that would instantly and effortlessly turn the development process into childplay.
I have no specific tool to suggest. I am busy writing design documents at this time but I have not found magic tools to help me. I guess I would like to use a database rather than a dumb word processor to make my documents easier to browse, manage, sort by functions or objects. I would like to see easier diagrams and charts or languages to describes workflows and UI without having to read tons of boring books or deal with complex concepts. I am always puzzled when I look at what Visio offers in its shape library for that matter.
However I still think that the design process is probably more important than actually writing the code. Bad code can usually be sorted out by QA, but bad design will show  up in your software forever.
Another interesting aspect is team management and communication. Not only should you have regular meetings but you should make sure that everyone participates in these meeting. The purpose of meetings is to have people expose what they have achieved, set up new goals to be attained by the next meeting and bring up new ideas.
I have seen too many meetings where a few people perorate endlessly to make themselves sound important and this is a complete waste of time. If you can't have useful and organised meetings it's probably better not to have any..
Working together as a team is another problem. Apparently the problem you are dealing with. People have to consider other people ideas, even encourage them. The attitude of the guy who will only do what he thinks is right without listening to others is damaging and counter-productive. This is really a major problem that should make its way into the head of our managers. Bad teams simply mean bad software.
Thursday, January 20, 2005

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

Other recent topics Other recent topics
Powered by FogBugz