Letter to a Colleague

I don’t know if you’re
familiar with this book,
but it is the definitive catalogue on the most common design patterns that are
in use in object oriented systems.  You will often hear these four authors
referred to as “Gang of Four”.

Perhaps the biggest name in this space is one Martin
Fowler.  His book, Patterns of Enterprise Application Architecture,
is the definitive book on building enterprise class applicaitons
(and what that means is open for debate).  This book and the concepts are
important as you will find, repeatedly, that many of the projects that come out
of Microsoft’s Patterns and Practices Group reference patterns that are
documented in this book (see the bibliography) section of the Enterprise
Library.

Note that both of these books are language agnostic
and, instead, cover the concepts that go into building interoperable,
maintainable, and reusable code.  In fact, you will find that both of these
books and the concepts mapped out within are extremely common in the J2EE world
and are only slowly trickling down in the .Net/MS space due to the leadership
position that the Patterns and Practices group has taken with the release of
Enterprise Library, but more importantly, the birth of .Net.

While I’ve read through the GoF book, I have not had a
chance to delve into the PEAA book yet (it’s next on my list of books this
year).  And, as I mentioned at lunch, even with a full understanding of these
concepts, it’s rare that people will come with a full design first.  It’s an
organic process of building, refactoring, rebuilding, and so on.  You must
absolutely have the right type of working environment and leadership to make it
work.

One common problem that arises when you read this book
is that the concepts in it are fairly useless unless you can get everyone in
your team to buy into it.  For that to happen, everyone has to understand the
common language.  And for that to happen, everyone will have to have read the
books.  Since very few consultants that I’ve met actually read text on this
level (abstract, general principles), it’s a rarity to be able to discuss design
patterns with other developers and it’s simply not worth the effort unless the
development team is really looking to learn (I’ve been in one environment where
the GoF book was purchased for every member of the dev team and required
reading).  Actually, prior to coming here, my plan was to do a “book of the
month” deal with one of my co-workers at [Company A] whereby we’d consume one book a
month on software engineering practices (be it architecture, programming
philosophy, computer science “classics”, or whatever) and discuss on a daily
basis (a chapter a night, 30-45 minutes of discussion in the morning).  I think
this is really the only way to improve the development practices of an entire
organization…you must have people that are willing to learn (and sacrifice
time to do so) and you must have leadership that is willing to sponser and
encourage such learning. 

In most environments, like [Company B], when consultants
are hired, they are not hired to bring in best practices and build reusable code
or act as software engineers; there is no concept of fostering better
development practices because the leadership cannot see the value in it (indeed,
the value is abstract and is only tangible in the future).  In these
environments, consultants are viewed as extra hands to write code.  It becomes
the decision of the individual consultant as to whether he/she chooses
to utilize these design patterns (or any OOP practices at all).  When used in
such a way, the power of building reusable code is highly limited as developers
are essentially working in isolation until integration (which defeats the
purpose going through the trouble of creating reusable software).  In
all honesty, you will only see such practices in software development shops,
smaller companies that have leaders that buy into these practices and patterns,
and places where there has been a “grass roots” movement by developers to
improve their skills.  In the large organizations that I’ve worked with,
including [Company C], [Company D], [Company E], and [Company F], only [Company F] had developers that were actively pursuing better development
practices.  And even there, only a small group of them (only two that I met)
were capable enough to do so.  I briefly worked with one developer at [Company Z]
(before we were [Company A]) whom also shared a passion for software engineering
practices and design principles.  Unfortunately, he left the company in May/June
of last year in what was a very disappointing day for me (it’s always upsetting
when a company cannot retain top talent like this guy).

In my situation, as I’ve mentioned, I’m not one to
force my views on other developers, especially ones that I’ve not worked
with.  Even beyond that, as I’ve mentioned, it’s a collaborative effort; it’s
pointless to speak the language of design patterns, abstraction, and building
reusable code when no one else understands and no one else has interest in
learning it and this culture at [Company B] does not encourage it.

So, that’s my take.

You may also like...

1 Response