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.

-Michael

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 <[EMAIL PROTECTED]>
To: Provo Linux Users Group Mailing List <[email protected]>
Sent: Thursday, February 15, 2007 11:13:54 AM
Subject: Re: Software Engineering (was Re: Java)

On 2/14/07, Michael Brailsford <[EMAIL PROTECTED]> 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.

-Bryan

/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/




/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/

Reply via email to