Re: Rule against Circular Dependencies?

From: Ken (kk_oop_at_yahoo.com)
Date: 04/26/04 

Date: 25 Apr 2004 19:44:03 -0700

> Why are you writing a OO design standard, if you are unsure of what
> should be in the standard. Standards are written once you are *sure*.
> Standards are written by a group of people who are so sure about
> things that they can all agree. Premature standards cause angst,
> wailing, gnashing of teeth, wasted effort, and are eventually ignored.
> Take care.
>

Thanks for your reply.

I have learned much about OO from your books and from feedback on this
newsgroup--and I am sure I will continue to do so.

That being said, I've got to tell you that whenever a standard is
suggested, there's always someone who says that you shouldn't have a
standard because everyone should trust each other and no one would
follow the standard even if there was one. I'm afraid that in the
real world, such utopian ideals don't always apply. In fact, on the
rather large project that I am on, some key C++ programmers actually
use the "trust everyone" idea to justify having things like public
class members and global data. "Why should we make data private?"
they say. We can trust that people will only use the data they need.

The reason we really need a standard on our project is to enable us to
prevent folks like that from using things like public data. It is an
unfortunate fact that good OO design and code takes extra time up
front to make. Anyone can sling together tightly coupled messy code
quite quickly. In many real world environments, people who don't know
better have their hands on the purse strings and the schedules. What
they want to see is the project done quicker. They don't want to hear
so much of investing early on in well thought out design and code with
maintenance and upgrade payoffs down the line (they'll have already
gotten there awards for finishing on time and under budget and will be
on some other project long before "down the line" occurs). For this
reason, the hackers often have their way.

Getting a design and coding standard approved helps this problem in
two ways. It sets the worker's expectations as to what is technically
expected of them; and it gives contractual teeth to the "best
practices" contained within the standard. This latter bullet helps
the well-meaning tech folks have confidence that they will have
management support when they say they don't want to just sling code to
get it done quicker.

I do think that it is critical to get input, concensus and buy-in on
the standards from a project's tech leads. Once that is accomplished,
potential schedule and cost impact of doing the job correctly can be
presented in the context of conforming to the approved standards. So
there is a very pragmatic rationale for having such standards in
environments like mine (just as there are very pragmatic rationale for
not having them in other environments).

Pehaps ironically, because of the experiences I've had applying your
OO principles, many of them will find their way into our standards,
for good reason (especially OCP, DIP and LSP). We also will apply
many of Scott Meyers C++ recommendations.

In the end, not every group has the luxury of being staffed entirely
by OO gurus (do any?). And not every group has the luxury of having
everyone willing to learn and apply best practices on their own, and
not every group has the luxury of having upper upper management who
realize the benefit of investing extra time up front to end up with a
better product in the end.

Having concise, well articulated OO-coding and design standards is one
mitigation for these problems. I would agree that these standards
should be limited to rules that are most critical to mission success,
and should not overflow with one guy's opinions (thus the need for
concensus).

I also am not above asking for input as to what the critical rules
should be. I am learning now, I will be learning tomorrow, and I will
continue learning until the day I retire. No shame ever in asking
advice of my peers. And in my opinion, most folks who are *sure*
rarely should be.

All that being said, thanks for your concise and useful response to my
actual question. :)

See ya,

Ken

Relevant Pages

  • Re: UL/ETL Choking the market
    ... If they mandate safety levels, it will take a LOT longer to do the tests ... due diligence and proper design analysis ... don't need to be tested, for example, I've attended Standards ... | Europe specific, but is much more sensible and there is no financial ...
    (sci.engr.lighting)
  • Re: UL/ETL Choking the market
    ... As a lighting designer with a lot of experience outside the US market ... In most of the world, standards are written to require manufacturers, ... design freedom the least possible, with descriptive, performance based ... It costs construction clients enormously. ...
    (sci.engr.lighting)
  • Web Systems Analyst-Permanent Position-Mt. Laurel, NJ
    ... Will design, implement, and administer web-based solutions for Web ... Work with external web site hosting vendors as one of the ... ·Create and enforce standards, best practices, and improved ... Services, XML, XSL technologies. ...
    (microsoft.public.vsnet.vstools.office)
  • Re: JTF: Javascript Unit Testing Farm
    ... I recommend everyone visit his site to judge his skills in web design ... I have never and will never judge a website on standards compliance. ... judge on content, usability, readability, marketing skill and visual ... we will fix as many of the worst bugs that web developers hit ...
    (comp.lang.javascript)
  • Re: BSD Questions.
    ... >>> firefox but that doesn't ... >>> People who design for IExplorer are bad! ... >> site needs to be well tested on AOL, ... >> reality the standards should follow MS, ...
    (freebsd-questions)