Links
·
RSS Feed
Popular Pages
 |
 |
Even though our group was already following many of the practices outlined in Ship It!, I believe the book paid for itself within the first day of purchase. When one considers the burn rate of a ty...
-Steve Mitchell |
 |
...Much like the Mac, this book “just works”, because it takes the best from lessons learned from team leaders and team players and takes the mystery out of the project management processes as appl...
-Robert Pritchett |
|
I haven't had the chance to read and review any books from the Pragmatic Programmers series. I decided to change that with the book Ship It! - A Practical Guide to Successful Software Projects by ...
-Thomas "Duffbert" Duff |
|
|
|
|
(Aug 19)
Last week I was talking with a friend about a common ailment on development teams today. And it seems to be getting worse.
Perhaps you've seen it already in your shop. Once one person catches an STD, it seems to spread quickly.
STD, of course, stands for Shiny Things Development.
Oh cool! Check that out... it's new and cool. Let's include it in the product! Why? Umm... it solves some problem. And didn't I just say it's shiny and new?
How many shops have you met that have insane development infrastructures "just in case" things get crazy? Anytime the shop has a list of tools and libraries where every single one requires a specific version for anything to work, someone there has STD.
What's the problem with STD? It generally indicates a lack of discretion and promiscuous use of technology. Rather than saving yourself for something that actually works, you're chasing down every new product and technology. Sure, it might be fun to try out new stuff, but over time the fun is far outweighed by the problems. It's never fun in hindsight.
If your product stack is just as complicated to understand as your product is, you're infected. If team members can't get parts of the product working locally, you've got it too. Have you every patched a single toolkit locally? That's okay. When you've patched more than a dozen, it's not the rest of the world, it's you. Have you rewritten large parts of a new toolkit, just to get it working? And it never occurred to you to just dump the new tech? It's just a matter of time until parts start falling off.
But there's still hope. Unlike some human STDs, software STDs can be cured. It takes time and discipline. You'll have to step back and eliminate some of the more trendy technologies from your product. A few doses of YAGNI usually clears things up nicely.
Here are a few guidelines for spotting trendy ideas:
- you've patched anything locally because it just doesn't work
- an update to a toolkit always breaks the application
- you spend more time isolating which area a bug is in than you do fixing the bug
- you have a list of tech for new developers to install that usually doesn't get them up and running
How will you know when you've eliminated the problem? When new team members are up and running in a day. When you spend time adding features and supporting the product instead of trying to figure out whether the latest bug is in LDAP, the database, the application.
When someone introduces you to a cool new toolkit and you can only see the potential problems it can cause in it's zero point one state, then you're on the road to recovery.
Category: Agile
|
|
|
|
|
|
|
|
|
|
The RubyRX and AgileRX conferences are colocating in Philly
|
|
|
|
|
|
The RubyRX and AgileRX conferences are colocating in DC
|
|
|
