Links
·
RSS Feed
Popular Pages
 |
 |
Ship It! is part manual of best practices, part software methodologies book and part a distillation of ideas and experiences of good and bad projects that the authors have been involved in. It migh...
-Tech Book Report |
 |
With much code, all eyes are shallow
-Jared Richardson |
|
It's rare to have this much fun reading a book about software. The ideas are smart, relevant, and fundamental. I can be a better programmer today because of the things I read today.
-Joe Fair |
|
|
|
|
(Oct 3)
We've got a number of classes coming up (some really soon!) and I wanted to push the information out to everyone. BTW, all classes can be seen at NFJSOne.com.
Test Automation Training, DC: October 8th-10th
Test Automation Training, RTP, NC: November 17th-19th
Test Automation Training, Chicago: December 10th-12th
This class is suitable for both testers and developers, but does have a strong Java focus. It'll be just as much strategy and tactics as it will execution though, so don't stay away if you're working in a different language. (Also, we've got a potential class where we'd rewrite this in C#... no promises yet though.)
How do you introduce test automation? How do you support those efforts, and ensure success? What areas should you be testing? What are the traits of a great test? What's the checklist for test automation on your next project?
Product Owner Training, RTP, NC: October 27th and 28th
We'll be looking at the best way to get information from your customers, then how to manage that backlog. We'll examine techniques and ideas for breaking down the big ideas, getting customers to prioritize, etc. (This is not a Scrum certified course, btw).
This class, by the way, is a direct result of a company asking for the training. We're customer driven. ;)
We're still building out courses based on customer requests, so please let us know what other topics you'd like to see covered or cities you'd like to see us visit!
We've also got a referral program that can put $$ in your pocket. Send us mail at contact@nfjsone.com for more information.
Thanks!
Category: Agile
(Sep 27)
I got email from Chris Sims this week asking me to mention Agile Open California 2008 on my blog. Here you go Chris. :)
Last year I attended Agile Open California 2007 and was so impressed
that I volunteered to help organize it this year. The conference is
not-for-profit and an amazing bargain at only $250 for two days. I
blogged about it here: http://blog.technicalmanagementinstitute.com/2008/09/agile-open-cali.html
I think it would really help get the word out if you would mention
it on your blog. Feel free to steal my text, modify it, or what-ever.
I not only stole his text, I stole his entire email... ;)
Good luck Chris!
Category: Agile
(Sep 24)
Many of us are familiar with The Pragmatic Programmer. One of the better known concepts from the book is broken windows.
The idea behind broken windows is simple. Once a single window in a building is broken, the other windows are more likely to be broken and the building vandalized. The only way to keep the entire building in good shape is timely repairs.
The concept maps well to compiles and automated tests. Keep them clean and creeping problems never get a foothold in your product. If you break something, fix it as soon as you notice it.
But this weekend at the Pacific Northwest Software Symposium in Seattle, an attendee told me about a new spin on this classic concept.
Mark Copec (who works at Contigo) mentioned a psychology study dealing with littering. The study showed that people were more likely to litter in a dirty parking lot, but a clean parking lot stays clean.
Just like the better known broken windows principle, the dirty parking lot principle tells us there is only one way to keep our projects manageable. Keep them clean every day. Run a continuous integration product (like Hudson or Cruise Control) and fix every break. Once the product has 117 broken tests, no one looks to see if there code commit had any affect at all on the test suite. Too many broken windows to count.
The study, Conformity: Influencing Behavior, raises some interesting issues. We can influence the behavior of our coworkers by keeping our own areas clean.
Mark summed it up well when he said "It got me thinking again about the different types of norms that influence people's behaviour, not only litter and parking lots, but also, developers and their coding habits."
Quick! Tell me... is your parking lot clean right now? No? Go clean it up.
Category: Agile
(Sep 23)
David Starr of Elegant Code interviewed me a few weeks ago and got it posted yesterday. I've "known" David for several years, but we still haven't met in person. This was the only non-email conversation we've ever had.
Topics covered include introducing agile, career tips, and more. And as an added bonus, you'll find a few pics of David dressed up as the MSN Butterfly. :)
Code Cast 14- Jared Richardson
Enjoy!
Category: Agile
(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
(Jul 1)
The Agile It! Experience (aka Agile ITX) finished up this weekend and was a great success. The speakers were all top rate. The audience was educated and engaged. We had great interactions and great questions. I brought my daughter Hannah along and she walked the fine line between entertaining the audience without annoying them. Other than me bashing my head into the side of the swimming pool (ouch!) and having too many managers (and not enough management related talks), I can't think of a thing that wasn't stellar. Next time I'll bring goggles to the pool, and I can guaranty we'll have the management track topped out next time around.
Here are a few related links summing up the conference:
David Bock from a speaker's point of view:
Agile IT Exchange Conference
And Mike Witter's attendee point of view:
Agile IT Experience… 5 closing thoughts
Here's our expert panel discussion. I got to emcee a blue ribbon panel taking questions from attendees. It was late in the evening and I ended it about 8 pm, but it's good stuff.
Agile IT Experience 2008 Panel Discussion - Agile Marketing, Culture, Jokes
The entire conference went extremely well... and you'll be seeing more of them in the future.
Category: Agile
(Jun 30)
Jennette Mullaney was kind enough to attend my talk Continuous Integration, The Cornerstone of a Great Shop talk in Las Vegas. We spoke for a bit afterwards and she put it all together into a nice interview.
Continuous integration reduces bugs, increases productivity
Enjoy!
Category: Agile
(Jun 3)
Ken, one of NFJS's best speakers, speaks tonight at Agile RTP. He'll be giving his well-known Iteration Zero talk.
I may not be there (my wife's under the weather), but Ken's a great speaker. If you're in the RTP, NC area, I'd encourage you to come out.
Category: Agile
(May 6)
Just a quick reminder, if you're in the RTP, NC area, come join us tonight and hear Andy Hunt.
We're also raffling off a pass to the Research Triangle Software Symposium, the local incarnation of the popular NFJS Java conference tour.
More details are on the meetup page
Rumor has it that Andy might exercise the speaker's privilege to change the topic to the future of Agile. See you tonight.
Category: Agile
(May 1)
I frequently hear the question at conferences... sure, we all know we should write tests, but it's like exercise. I know I should, but I don't. It would take too much time.
Recently I've been telling people that it takes only 10% of their time to create automated tests. And then I tell them about this blog entry. I decided to link to it so it'd be easier to find.
Automated Testing -- It's the thought that counts
At 6th Sense Analytics, we collect process metrics, so this is just an example of the type of insight we can pull out. After the tests were created, we knew exactly how much time was required.
Category: Agile
|
|
|
|
|
