Software Engineering (was Re: Java)

Michael Brailsford brailsmt at
Thu Feb 15 11:02:44 MST 2007

Naw.  I'm fine where I am at.  I don't think I would know what to do at company that actually has implemented high quality software engineering practices.  It should be pointed out that company where I work is not actively working against software engineering, in fact my management encourages my efforts to improve what we already do.  I *do* however have to work with code on a daily basis that is legacy code by any definition.  I do not think that is strange.  Most of us has had to work on code from engineers that can code anything under the sun, they just neglected to consider such things as design, documentation and maintenance.  It is no coincidence the engineer(s) who wrote the code I complain about are no longer here.  On the flip side, there is a certain culture at any place of employment.  Any change to the status quo is met with resistance.  I like to think of it as momentum.  People who are entrenched in "good enough" are reluctant to do new things, though they might agree that those things are needed and are indeed an improvement.

One of my favorite quotes is:
 There are many factors that can contribute to software rot.
The most important one seems to be the psychology, or culture, at work
on a project. 
- Dave Thomas and Andy Hunt in The Pragmatic Programmer.I happen to be doing some great work, and making a name for myself, while working on a great product that can really help people.  That is important, and is one of the reasons I am content staying where I am at.

I stand by what I said though, I cannot tell you how many times I have heard "code is documentation".  I *am* holding up open source software as a beacon of high quality software.  The open source world is very organic.  Projects are born and die every day.  Only the best make it, survival of the fittest.  This tends to bias the field towards creating software that encourages flexibility and which has lower maintenance cost.  This is usually accomplished by good (or at least decent) design and coding practices along with a significant amount of constant refactoring.  There is a different set of rules at work in the world of the Cathedral.  Those rules do not favor the better solution in many cases, rather the solution with better marketing and deeper pockets or the first to market.  Think Microsoft.

The environment you describe at your employer is utopian, and is the exception, not the rule.  Consider yourself fortunate.  I draw this conclusion after talking with 100s of Software Engineers from dozens of different universities.  None of whom value high quality engineering standards, in fact most of them have never been taught how to engineer software, as opposed to just coding.  It should also be noted that I hold BYU's CS curriculum in high esteem after talking with my colleagues about their coursework.  So if the people you interact with are predominantly from BYU or the UofU, then you are getting a higher quality sample of engineers.  I live and work in Kansas City, so I get quite a different view of software engineers than if I had stayed in Utah after graduating.


P.S.  If anyone works with a company outside UT that is looking to hire, by all means let me know.  I'd be a fool to pass on a chance to further my career.  :)

----- Original Message ----
From: Bryan Sant <bryan.sant at>
To: Provo Linux Users Group Mailing List <plug at>
Sent: Thursday, February 15, 2007 11:13:54 AM
Subject: Re: Software Engineering (was Re: Java)

On 2/14/07, Michael Brailsford <brailsmt at> wrote:
> How funny, you equate professional with documenting code.  I about fell out of my chair laughing so hard...

Yes, a true professional "software engineer" will follow software
engineering best practices.

Proper code documentation is critical.  Where I work, documentation
and unit tests are required.  Code and documentation is peer reviewed.
 This hasn't aways been the case with every company I've worked for,
but everyone has desired good documentation -- they just didn't
necessarily enforce it.

> Most professionals in my experience think that the "code is documentation".  Its a big macho thing.  I guess I am too stupid, and I always ask what exactly they were thinking

What kind of a slip-shot company do you work for?  What a joke.  I'm
not saying that this isn't common, but the attitude of your co-workers
disqualifies them as high caliber professionals in my book.

> Who knows, maybe I just have had a bad experience, landing at the companies I have worked for.  No, I'm pretty sure my experience is normal, I am experiencing first hand just exactly what "The Cathedral and Bazaar" is all about.

There is open source code with good documentation and a whole lot more
with no documentation.  If you're holding up open source as the
standard for good documentation, I'd say you're using a very selective
eye.  Open source is great, but obviously there is no standard that
any project is held to (other than self imposed quality standards).
The good/popular OSS projects typically have good clean code with
consistent code style and documentation.  The other 90% of OSS
projects are just goo that someone threw out there.

Quit your current job and find a real software shop to work at.


PLUG:, #utah on
Don't fear the penguin.

More information about the PLUG mailing list