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.

Big up-front design!

Joel wrote "I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that". This was interesting to me and I wrote an article on my blog http://bdory.blogspot.com/ to discuss about the myth of "Big Up-Front Design". Have a look and give me your ideas.
B Nguyen Send private email
Saturday, August 20, 2005
 
 
Results 1 - 10 of about 4,300 for bduf. Most of the first hits are about the topic.

Results 1 - 10 of about 910 for bufd. Most of the first hits are about buffers and such.

Don't confuse your acronyms. My first impression on your article was that you are talking about a similar, but different thing. And don't knowing how the things are correctly called always gives the impression of one not knowing what he is talking about.

Sunday, August 21, 2005
 
 
Good catch. It's should be Big Design Up-front (BDUF) instead of Big Up-front Design (BUFD). I've never use acronym for this thus make this confusion, but the idea about them is the same -> it's a debate about how much do you design and when do you design!
B Nguyen Send private email
Sunday, August 21, 2005
 
 
Well, at least you didn't write BFUD. (Big F'd-Up Design)
Nick Hebb
Sunday, August 21, 2005
 
 
"Well, at least you didn't write BFUD. (Big F'd-Up Design)"

I've worked on Big F'd-up Designs, they are no fun.... but your remark is funny... :)
PPR
Sunday, August 21, 2005
 
 
B Nguyen:

I read your article comparing BDUF vs XP and liked the way you showed the similarities bewteen Joel's view and Kent's, even though they describe their positions as opposites.

I was wondering if you have any thoughts on CMMI.  I can't make heads or tails out of it.  The articles I read on CMU's website didn't seem to have a single statement in them I felt I could sink my teeth into.

Have you read/thought much about what CMMI is and if it has any valuable lessons to teach?
Chris Marshall Send private email
Friday, August 26, 2005
 
 
Chris,
I am working in a CMMI level 5 certified company and I want to share with you my thinking about it. But as you asked about what it is I also give a brief overview here.

Basically, CMMI is a model which guides the process improvement activities of a software organization. The model is based on the so-called industrial "best practices" that already applied successfully by the leading organizations. As a model, it defines the goals and practices that a company must meet in order to improve their process. CMMI defines 5 levels of improvement: initial, managed, defined, quantitatively managed, and optimized; each with each own goals and practices (called PA - Process Area). An example of a PA in level 3 is "Risk Manage" which identifies the goal that you need to accomplish with this PA as well as the practices that help you accomplish the goals. In order to be certified for a particular CMMI level, the company must meet all the PA's of that level and those of the lower levels (in fact there is another way to archive CMMI but the method I mention, called "staged represetation", is much more popular). When a company has implemented all the PA's of a certain level and want to be CMMI certified, it will register for assessment and an SEI authorized party will handle the assessment. An assessor will visit your company for a few week in order to perform the assessment. Basically, he will look at your projects' artifacts to see if the practices of the level are followed as well as other indirect artifacts such as software quality, design quality etc. Moreover, oral interview sessions are also taken place between the assessor and many people in different roles of your organization to make sure that people indeed understand and follow the process. After all these, if everything is OK then the organization is certified.

Based on the "internal" look at the process of my company, I myself don't have a strong interest in CMMI for the following reasons:
-It is not well assessed. Why I say this? Because in my company case, there is just 1 assessor who performs all the assessment of the accomplishment of goals and practices. You can easily agree with me that one person can hardly assess the quality of a process. As a result, the assessor seems to be focused more on what he can do well, e.g. the practices. No matter how hard he tries, he simply cannot assure that all the practices leading to great outcomes. As a result, it is very tempted to perform the practices just because they are required by CMMI. Sometimes, the practice can be faked (or "cooked") just to be able to claim "look man, we have that practice... wait for what before certifying us?". For example, to accomplish the peer review practice you just need a set of peer review records and I myself have to "invent" many review records in the assessment period so that they can be used as "evident" of process implementation ;-). This is just bullsh*t.

-After an assessment, the company usually keeps on with the "practices" that they have in place even if they are simply bad and not appropriate. The reason is that there is a pressure from the top management that "as a CMMI Level 5 company, don't say that we don't apply a CMMI Level 5 practice". The result is that we have to do things that we are in fact not "mature" enough to do.

-Many companies archieve CMMI just because it will make them look good in customers' eyes, hence, increase their competitive advantage, not because they really want to improve their process. This leads to "quick fixes" - in which they try to cover their bad quality under elaborated documentations in order to get certified.

-It asks for too much in this world of change. In fact, I don't think that most organizations can *really* archieve a level 3 CMMI simply because it requires us to do too many things while in fact not all of them are beneficial to our problems ;-).

-All of this makes CMMI not 100% trust-worthy, and it is the customer who pays for this non-trust-worthy certification (s/t like, "they are CMMI L 3, their process must be well defined and repeatable, so we are willing to pay a little more money...")

To put it simple, CMMI *maybe* good if your organization is "really" mature. My advice is that an organization should not focus on CMMI as a goal, because it easily leads to apply the practices blindly while not mature enough. Instead, the organization should focus on continuous process improvement, and when they are "mature", then CMMI "automatically" comes. If CMMI does not come, it means we are simply not "mature". That will be a more beneficial way of archieving CMMI. It is just like to achieve an MCSD.NET you have 2 possible ways: continous improvement and one-shot braindumping. The latter gives you the quick result and it makes you look good in your CV, but it does not help with the fact that you are dumped (1) ;D.


(1): I'm an MCSD.NET by the former way :D.
B Nguyen Send private email
Sunday, August 28, 2005
 
 
B Nguyen:

Thanks for writing such a long and informative reply!  You've been very helpful.

If I might paraphrase your reply:

1. CMMI defines a number of best practices for managing software projects.  This would include how to document, plan, review the status of, and maintain a project.
2. When being certified, an assessor comes to your company to look over the artifacts of the projects you have completed to see how many of the best practices you are following and how well you are following them.
3. Doing a good job of assessing requires more effort (=people) than is typically spent on it, so faking the artifacts is possible and not that unheard of.

I take it you think the CMMI concepts are good ones as long as they apply to the situation at hand, but they don't always, and people are trying to apply them where they don't make sense simply to keep up the appearence of "doing CMMI."

I am still scratching my head at how little I was able to learn about these best practices from CMU's website on CMMI.  There was nothing I could sink my teeth into.  No concrete case studies, which I think would be the only way to meaningfully discuss such best practices.

Can you recommend any books or articles that do a good job of teaching any of the CMMI best practices?
Chris Marshall Send private email
Monday, August 29, 2005
 
 
//CMMI defines a number of best practices for managing software projects. This would include how to document, plan, review the status of, and maintain a project.
Nguyen: not just about software management, it's about both short and long term activities of software development such as: coding, designing, verification & validation, configuration management. Everything you name ;-).

//2. When being certified, an assessor comes to your company to look over the artifacts of the projects you have completed to //see how many of the best practices you are following and how well you are following them.
Nguyen: yes, that's true.

//3. Doing a good job of assessing requires more effort (=people) than is typically spent on it, so faking the artifacts is //possible and not that unheard of.
Nguyen: yes, more effort should be spent in order to assure the that the organization not only follows the practices (practice-focus), but more important is to assure that it follows correctly which results in a boost in development productivity and process predictivity (goal-focus)

//I take it you think the CMMI concepts are good ones as long as they apply to the situation at hand, but they don't always, //and people are trying to apply them where they don't make sense simply to keep up the appearence of "doing CMMI."
Nguyen: CMMI PA's defines the goals & practices to help the process improvement of an organization more productive and predictable. In order to be productive & predictable, the project needs to meet different goals and carries out different tasks and produces a large amount of work artifacts. IMO, this is more good to mission-critical software projects or projects that have highly stable requirements (very few ;D), for most kinds of projects I think this as a burden to carry out all the stuffs - in fact, CMMI does not require all projects in an organization must follow the same sets of things, and some tailoring guidelines are application; but the expectations from the top management demand CMMI "best practices" to be followed. This is more of a problem of management than a problem of CMMI.

Nguyen: My conclusion is this: CMMI has many industrial proven "best" practices. The goals & practices of CMMI will guide the process improvement of your software organization - i.e. "Hey man, you want quality but don't know how? Implement your process with these practices (blah blah blah) so that it meets these goals (blah blah blah). From this you will know how to organize your corporate-wide training, how to setup a process improvement group, how to perform verification & validation properly, how to assure work product quality with peer review etc.". The problem is that practices are easy to follow (I mean follow blindly) but goals are hardly accomplished ;-). Process improvement should be "goal-oriented", not "practice-oriented" (the very bad thing is that practice-oriented usually offers you a CMMI certification).



Can you recommend any books or articles that do a good job of teaching any of the CMMI best practices?
Nguyen: I know no good book, as usual Amazon is a start for you ;-).
B Nguyen Send private email
Monday, August 29, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz