This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
Current Efforts:
Blue Parabola, LLC
CaseyMultiMedia
web2Project
PHP'ers:
Ben Ramsey
Brandon Savage
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
DC Social Media:
Aaron Brazell
Jessie X
Shashi B
Business/mISV:
Bob Walsh
Eric Sink
Gavin Bowman
Guy Kawasaki
Joel Spolsky
Micah Baldwin
Paul Graham
Planet mISV
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
phpUnit
Subversion
Zend Framework
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
After my post last week on "The Broken Window Fallacy in Software", it was clear that there was a misunderstanding. In terms of Broken Windows, there are two types..
First, there's the Broken Window Fallacy which is an economic explanation which dates back to the 1850's. The principle idea - which I was building upon - is the concept that economic activity of any form is good for the economy as a whole. This completely ignores the fact that there are costs - often hidden - under any circumstances.
In the case of the Broken Window (or the "let's start fresh!" idea of software development), the primary actor in the situation loses control of their decision. They don't have the option of using the time/money/effort for something else, they must use it to return to the previous status quo.
Food for thought... If someone broke your window, it would be vandalism... what should we call it in software development?
Second, there's the Fixing Broken Windows idea which has its roots in criminalogy and psychology. It is built on the basis that accepting/allowing lower standards will result in even lower standards being accepted later. In the original analysis/discussion, the idea was that once a building has a few broken windows which are allowed to persist, other things will happen.
The Pragmatic Programmers - Andy Hunt and Dave Thomas - were the first ones (in my knowledge) to apply this to software. As you let little hacks and nastiness exist in your code, more will follow until the entire system is a mess of one-off hacks and a nightmare to maintain.
A variation of the concept is "A players hire A's. B's players hire C's."
Actually, I think they're more related than I previously considered:
It appears to me that our standards and expectations have been lowered so far that in many cases, we're happy if the damned thing works right just once in a while... and the person who can swoop in and provide a one-off hack to fix the immediate problem is the hero.
Why is that?
Why is that?
Everyone likes to be a hero. Solving a short term critical issue is usually more interesting and adrenaline producing than producing code to a schedule and a feature list. Immediate feedback and praise are forthcoming instead of "Are you going to have release x done by Thursday?"
It could be a combination of
It could be a combination of effects. First, software is hard. That's why it breaks a lot. Second, there is a business rush put on everything to do with software because, by and large, the business only gets value out of the software when (1) it is done, and (2) it is working. These two effects together create a situation where the software is often breaking (or "sometimes working") and there is a high value put on "just getting it working *for now*." I emphasize the *for now* because often times companies are driven by short term profits (especially with investors looking over your shoulder) and thus having it working now but hacky is better than having it working later and well thought out and intelligently implemented.
Do I agree with this general mode of operation? No. Do I think this is happening in a lot of companies? Absolutely.
Post new comment