[lug] can't make this stuff up, folks... My 2 lines of code, errr, I mean, my 2 cents....

[George Sexton]

I had some other thoughts on this issue.

 

A big problem in the developer world is platform/tool churn. In the Microsoft world, their development focus used to change every two years. Here’s a sample of their progression:

 

COM

DCOM

ActiveX Forms

ASP

Remote Methods/Web Services

.NET with WinForms

Silverlight

 

In the MS world, there was so much churn for development methodologies that few programmers wrote more than one major project using the same tools and techniques. As a result, every project suffered because the developers were learning how to effectively use the tools. A maintained project might have 3 different development methodologies incorporated. Total nightmare. I’ve left that world, so I can’t comment on how it is today; probably unchanged.

 

In the Open Source worlds, you have things like AJAX, Ruby On Rails, Zend, Grails. There’s always some new paradigm every 6-24 months in the Open Source world as well.

 

Programmers always want to use the newest tools because a) it looks good on the resume, and b) they’re hoping it’s a “Silver Bullet” that will make their project easier. Let’s face it, there’s never enough schedule time so we’re always looking for the magic to help make the schedule happen.

 

Another problem with the tool churn is that you’re always using immature technologies. The tools themselves have many bugs/design flaws that pound you. It’s tough to write a quality program using a new version 1.0 development tool, while adhering to a tight schedule.

 

If you want to write quality code, you have to stick with the same tools long enough to build a deep expertise in them. Additionally, the tool has to maintain and grow to develop a robustness and completeness.

 

I used to have a home-made poster on my desk:

 

“If you want to be on the cutting edge, you have to be ready to bleed.”

 

Lots of people want to be on the edge but don’t take the bleeding part into account.

 

George Sexton
MH Software, Inc.
 <http://www.mhsoftware.com/> http://www.mhsoftware.com/
Voice: 303 438 9585
  

From: lug-bounces at lug.boulder.co.us [mailto:lug-bounces at lug.boulder.co.us] On Behalf Of stimits at comcast.net
Sent: Thursday, October 22, 2009 2:40 PM
To: Boulder (Colorado) Linux Users Group -- General Mailing List
Subject: Re: [lug] can't make this stuff up, folks... My 2 lines of code, errr, I mean, my 2 cents....

 

....
You still need deep tests on critical code but as you implied you can focus on the things where it really matters.
...

This particular thread is too entertaining to not add:

Often unit tests and other tests are more important just to make sure the programmers are thinking correctly. Writing tests can be time-consuming and difficult, and the first thing it does is make the programmer think about what is going on. Sometimes it seems so simple when we sit down and write code, but then when we sit to write a test, it suddenly becomes clear if there was something we had not thought of. Unit tests are as much for the wetware as they are for the software. A favorite unit test of mine is to see if I can put good comments in the code...in this case the unit being tested is me.

Dan Stimits, stimits AT comcast.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20091023/7a45acc7/attachment.html>