Delivering vs Defining

After going to an internal conference this week, I was able to put my thumb on something that I couldn't since I started working for my current employer. That thing is the power of empowering your employees.

Overall, the internal conference was great. I applaud the people who put it on! The idea was to save money by having our own internal gurus from different departments present on various topics ranging from management, design, development, testing and systems. I enjoyed the topics very much. We even had James Gosling come and give us the keynote.

I particually remember a topic done by an old collegue that showed how he used Hadoop on to write a quick tool that solved a need.

The conference got me thinking and comparing the different departments as they presented on very different topics and technologies.

The first organization has a list of technologies that are blessed and any technology that doesn't fit that mold requires meetings and process for approval. There is a team who defines exactly what can and cannot be used and how those technologies should be used. This department is very worried about solving situations that might someday occur.

I remember, one day I was tinkering with Groovy and a member from this team came by and asked me why I was playing with a non-approved technology. That was a first in my career. I am used to something more like "Hey, that's cool! Does it have closures?" Another time, I had an idea that would help 5-10 technical people (non-paying customers). It would have taken only a few days to complete and I had nothing else on my plate at the time. The problem was I didn't have anywhere to bill my time so I was asked to document the idea and put it through a process where it gets prioritized, voted on by several other people and then finally, if found important enough, funded. The process takes at least two weeks; usually closer to 4-6 weeks. Instead of completing that idea, I spent my time doing other remedial tasks which I can bill my time to. Basically, very few of these ideas get done.

I have less insight into the other organization(s). I only have only had brief experiences with them. Basically, they seem to be about just getting stuff done and using whichever technology they can to get it done. They seem to be the ones pushing the bar on technologies and I haven't heard of a central approval board for technologies and processes.

The epiphany I had from the presentations given at this conference is that the department which was focused on delivering presented on more recent technologies and even trends while the other one presented on stuff that's been tried and trued for a while now.

The difference is one organization has a whole department of engineers who are expected and empowered to solve problems while the other organization has only one team of engineers who are expected and empowered to solve problems. The other employees are not expected nor empowered to solve complicated problems unless a problem fits in the 3x5 box that they are expected to think in.

Randal Schwartz interviews Kent Beck

Randal Schwartz interviews Kent Beck in this issue of FLOSS. They talk about TDD, patterns, Agile and where XP fits in there along with a few other topics. I worked with Randal while I was at Yahoo! and he is brilliant. For those wanting an introduction to the topics listed previously along with some other interesting facts, this is a very good listen.

Red-Green-Refactor

Red-Green-Refactor is a phrase created to help those practicing TDD (Test-Driven Development) remember the importance of the order of tasks. The premise comes from running the unit tests in some sort of GUI. When a test fails, the GUI displays a red bar. This red bar makes it easy to recognize that a unit test has failed. When a test passes, then the GUI displays a nice green bar.

The first thing to accomplish is to write a failing test (Red bar). This proves that the test is a valid test and will fail when the code is not implemented correctly. Once a red bar can be reproduced, just enough code to get the test to pass (Green bar) is written. The green bar is now a safety line. The new goal after the green bar is to refactor the code while keeping the green bar. Now that the safety line exists, as much time as needed can be spent on the refactor. After the code is refactored, then the process starts all over again.

I like to call it R~e~d/Green/R~e~f~a~c~t~o~r as the least amount of time is spent making the bar green while the most amount of time is spent refactoring and creating the test.