Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS

Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers

Blog Archive

Mon, 09 Jan 2006

Physical Feedback at Microsoft

As a follow-up to my early blog entry on Physical Build Notifications with Continuous Integration, I'd like to pass on another jewel.

John Brown sent me a link to a video titled Microsoft's We Share Your Pain (WSYP). It's a great program that could make a real difference in product quality in many different companies. I wonder if they'll license the system?

It's nice to know that all those error reports we send in are actually put to good use!



posted at: 19:31 | path: | permanent link to this entry

Observations on Corporate Culture and Agile Methods Adoption/Adaptation

Esther Derby had a great blog entry today on various corporate cultures and how they advance or impede agile software development. It's a very well-written bit.

Observations on Corporate Culture and Agile Methods Adoption/Adaptation

I see myself as a mix between Achievement and Relationship and bumped heads recently with someone firmly in the Bureaucratic camp. It's amazing how much easier it is to see the other person's point of view when understand how they view the world.



posted at: 19:26 | path: | permanent link to this entry

How to Write Really Bad Code

A humorous look at writing code that no one else can understand. This is a great way to start the week ~and~ remind you of a few practices that you hadn't thought of recently.


How To Write Unmaintainable Code

Here's one of my favorites so far...

Thesaurus Surrogatisation

To break the boredom, use a thesaurus to look up as much alternate vocabulary as possible to refer to the same action, e.g. display, show, present. Vaguely hint there is some subtle difference, where none exists. However, if there are two similar functions that have a crucial difference, always use the same word in describing both functions (e.g. print to mean "write to a file", "put ink on paper" and "display on the screen"). Under no circumstances, succumb to demands to write a glossary with the special purpose project vocabulary unambiguously defined. Doing so would be an unprofessional breach of the structured design principle of information hiding.

posted at: 19:18 | path: | permanent link to this entry