For the past ... probably 3 years I've tried to articulate this idea I've had into words that would make ANY bit of sense. I've tried various angles and had a few different theories and finally, this is what I came up with. Since my first attempt, I've witnessed different forms of this and have drawn a conclusion with utmost confidence.  "It's all about the people" isn't a cliché but solidly ... no one gives a damn and they should. Now, before you start saying "well duh" or make some excuse, hear me out. More...

Earlier this week I found myself in an interesting spot.  We had a hell of a bug come though that had no real reason for existing, much less any kind of answer to "how did this even get there?!".  Someone mentioned I should use git bisect -- I'd never heard of this.  It's a little strange at first, but once I got the hang of it, it's really slick.

Say for instance your on your repository on the latest and greatest and you find a bug was introduced ... say ... three weeks ago.  You don't know when exactly, but you know it was sometime in that time frame.  Grab a hash code, (treeish, the first few letters of the hash I'm told are usually enough for uniqueness) and go ... something like this ...

git bisect start HEAD <someHash>

and you'll see something like this ...

$ git bisect start HEAD <someHash>
Bisecting: 174 revisions left to test after this (roughly 8 steps)
[someMiddleHash] Comment for that commit

JRiley@JRILEY /c/Projects/Core ((someMiddleHash...)|BISECTING)

What git will do is say ok, somewhere between HEAD and <someHash> was a screw up, so it will pick the middle commit and give that as a starting point.  Build, do your dance and determine if its a good (problem isn't there) or bad (problem still exists) as such ... in my case, I'll say its bad.

$ git bisect bad
Bisecting: 86 revisions left to test after this (roughly 7 steps)
[yet another hash] comment for that commit

More...

This is just a link-puke of a bunch of articles I've been meaning to post/talk about.  So here we go (say bye bye to your morning)

First up, a mildly misleading heading of kanban vs scrum.  It's really how one can be used to streamline the other.

http://www.agilejournal.com/articles/columns/column-articles/6441-a-productivity-comparison-of-kanban-and-scrum

Next up are a pair of articles from the same site.  First one talks about overcoming poor architectural choices and a rather candid discussion on "disaster porn".  Love that description.

http://arstechnica.com/business/news/2011/10/when-clever-goes-wrong-how-etsy-overcame-poor-architectural-choices.ars

http://arstechnica.com/business/news/2011/09/google-devops-and-disaster-porn.ars

A couple psych ones.  First one is amazingly nerdy and in my opinion, expands on the feedback principle.  Random nerd fun fact - technically, Pe (error positivity) can be instantly recognized, which for the human brain is 130-180ms and falls with the range of the study which measured it at 100-500ms.

http://www.wired.com/wiredscience/2011/10/why-do-some-people-learn-faster-2/

and not to be outdone, a discussion on sugar vs protein and being awake.

http://www.wired.com/wiredscience/2011/12/why-sugar-makes-us-sleepy-and-protein-wakes-us-up/

Another article I found very interesting was on leading clever people (I agree with it, especially "create a galaxy")

http://business.in.com/article/rotman/how-to-lead-clever-people/28632/0

And finally, on a similar vein is a concept of "developeronomics" ...

http://www.forbes.com/sites/venkateshrao/2011/12/05/the-rise-of-developeronomics

Today at the office I gave a presentation on encryption.  Attendance was very very light (4pm on a friday, no surprise ... ?) and I was even asked if I wanted to reschedule -- na, I'll do it twice if I have to.  Wow did they miss out.  I had discovered that the methods of applying encryption were amazingly important, and I'll be damned if I couldn't replicated it.  I wanted to see this for myself as it broke every rule I had known or in other words, perfect.  First I tried hacking up a jpeg file until someone pointed out the obvious -- it's got it's own "encryption" and suggested I bounce it over to bmp, a raw format.  What a great idea and how did I miss it? But I'm getting ahead of myself, let me step back and talk about encryption...

Encryption in and of itself is very technical once you get into the modern age.  Very specific, lots of math, probability, etc make it a subject most people just glaze over and shut down.  I'll do you one better.  I see your glazing and raise you an awesome visual.  While doing my research for this presentation, I ran across something absolutely facinating which I touched base on earlier...

Encryption algorithm and of itself is not the whole story.  Not even close.  I'm seriously starting to wonder if, holistically, its method is JUST as important than its computation/execution.  Why?  Allow me to explain and consider this image. (warning -- shamelessness !!!) More...

When I was in college, one of the classes we were forced to take was psychology.  I had taken a class in high school, and looking down the list of items this class would cover, I was expecting another boring, useless class.  I was right, with a slight exception -- the professor, Tony Obradovich, I had not expected.  I took a second class per my own direction and made sure he was teaching it.  How awesome it was, and based on his reviews, he's still awesome today -- as I would expect.

Professor Obradovich would talk to us about the times he was a kid and would repeat things he would hear from authority figures (his dad specifically about someone following too close) and how his patients were struggling with different aspects of addiction -- most were drug, alcohol and I think even one sex addict. More...

I got the WHAT down, decided and finalized -- great, now HOW do we do this?  In theory, it's simple.  Add a few projects, a few references and start rockin and rollin.  What could possibly go wrong?  Well, everything.  When I started to move this forward, that was my thought "its just a couple projects and a few references" and off I went.  About two weeks later, a rude surprise showed up -- we have some servers on 2k3 without .net 4.  Someone copied a unit test dll that was in ... 4.0.  Also, there was some questions regarding the wording of the tests themselves.  Eugh.  So here's what we did... More...

If writing software is hard, finding a successful mentorship program is damn near impossible.  After a morning of research, talking to some former coworkers -- it just might be.

I was part of a mentorship program that had some serious gaps.  Along with being the guy that got mentor-switched more times than I care to admit, there was a lack of commitment, lack of leadership, direction and action.  I don't want to recreate those negative conditions but there were some good take aways - I did have one good mentor.  Still, that doesn't answer the overall concern I have : show me one successful mentorship program.  Hmm, that's a problem, feels more and more like it can't be done -- right up my alley. More...

Thanks again to everyone that attended the Atlanta Code Camp and of course, my talks.  I really enjoyed the discussions more than anything, especially the one about monkeys and as always, feel free to shoot me an email at je riley from the gmails of the com  (Suck on that spammers)with any questions.  Also you can find me on IM (gtalk/msn) and ...just about everything else with that email address, so feel free!

Kanban'in It Slides

Dynamic Slides

Gentle Intro to TDD

In part 0, I talked about how to understand or at least get a vague idea if your org is even ready.  So now it's obvious they're ready, they want to make it better.  Yay! ...now what?

You've heard the cliché if you fail to plan you plan to fail and as much as I hate clichés, it's true.  Between the inability to decide what to use, how to word your tests, where they'll live, how they'll be run, etc -- all this can get in the way of the real goal.  Saying focused can become a challenge here with the distractions of "WHAT".  Here's how I went about it.

0. Get management buy in.  In my case, it was under the direction of management -- they wanted it done and looked to me to help move it forward so this part was easy.  If you don't, approach it like you would any other proposal/business pitch/selling something.  Expect to defend it, back it up with fact and not emotion/fan-boyism.

0.5 Decide the framework(s) immediately.  Don't waste more than half hour on this.  Look at what options you have, what makes the most sense.  For my situation, MSTest was ideal and JustMock.  Are those my favorites?  No, I'd rather use nUnit and Moq but because of some business reasons -- MSTest is installed already on every single box, works with TFS out of the box and JustMock because we could seamlessly upgrade to the static-mocking version (free version doesn't include this).  Which leads me into my next point ... More...

Recently, I made a significant career move.  I packed up everything and moved to Atlanta.  When I arrived, I immediately jumped in and took on a feature (nothing like diving in) and learned a bunch about their current environment.  One of which was a complete showcase of how to do tests wrong ... mostly.  Integration tests mixed with unit tests mixed with tests I have no idea if they ever worked.  Some where commented out, some didn't do an assertion -- you name it, it's in there.  I did some asking around and found out they HAD tried testing, multiple times no less, but because of the time to test (4 hours !?) and lack of quality, they turned them off - COMPLETELY.  This told me a couple things - they wanted to do testing and they didn't know how.  At least not on a level that was acceptable.

I sat all that aside and focused on what I had in front of me : an unwritten, new feature.  A perfect target and golden opportunity to show by example.  I didn't ask, I just did.  It was a complete success.  There were quite a few factors in this, most of which were outside of my control.  It was a team effort, as it should be.  So how do you know if they're ready to "do it right"?

0. A solid list of requirements ... or the ability to go and get them.  The requirements I received were well thought out, had events/actions and made it very clear what they expected it to do.  My resulting unit tests were near carbon copies of those requirements and also helped me expose holes in the requirements early on. More...