Opinion : Lack of Interaction is a self-fail

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...

"I don't want to be involved in software"

I went to the path to agility conference yesterday and a short story caught my attention.  Ken Schweiber talked about a neighbor (I think?) he got an internship for doing some QA work for a software company.  After their graduation, he offered to help get them a full time job - the answer was amazing : "Hell no".

Because of this person's experience, there was no desire for that person to go into software dev.  Horrible code quality, missed deadlines, angry unhappy people, the toxic cocktail that can kill any project (and morale) was rampant.  Sure you could argue that's an isolated experience, but is it really?  I'd like to think it is, but it isn't.  Worse, I know someone I think is on that edge, to the point of NOT wanting to be in software anymore.  Frustrated, feeling left behind, etc, I decided to dig a little bit into this - I genuinely want to know where this profession began to break down and fail to serve the person that at some point enjoyed it.  I love software, I think it's fun but that's not the whole picture.  I invited this person to lunch and what I nailed down as the answer is one you've heard before. More...

Opinion : What happens when failure is not only an option, but assumed?

I've been on a few projects recently where "no one wants it", "no one wants a part of it", "it's terrible", "oh you're on that ... good luck" and every type of don't-want-it you can imagine.  The type of project you -really- want to ask the people that were there before and ask them just WHY.  The client knows it, you know it going in but you do it anyway.  Then something totally unexpected happens... it doesn't fail.  It may even become an amazing success, and even more oddly, it usually does.

So why don't they fail?

Since I've been off a particularly challenging project, I've had time to not only be on another failure assumed project, but think about what happened.  Interestingly, a video game summed it up.  There's an intro in modern warfare 2 that talks about the characters being on a suicide mission.  They know they're going to die doing this, but there's a bit of liberation, a freedom that occurs when you know something is -going- to end but you get to decide that outcome.  It releases your mind to do things you normally wouldn't consider acceptable, much less possible.  "It's stupid enough it just might work" is a requirement.

This is where the original problem was kept, hidden from view.

I've now sat here for half an hour, writing and rewriting an explanation of a blend of contained creativity and fear of failure seem to truly cripple projects.  I can't come up with concrete examples nor even theoretical examples -- yet somehow the argument still seems valid.  I'm not sure if the expectations need to be adjusted, such as on style.  Who says "this is the way yee shall render a grid!" ... there's reasons why cars, homes, businesses all look different.  When people are told "we have no idea how this is going to work, but we want to you to <accomplish something>".  Maybe a focus needs to be on the resulting end goal instead of all the problems on the way?

To return back to my own promise of posting "how long did this take" -- this post took 2 hours and one review by someone not in the tech world ... at all.

Ask the right question, get the right answer

Talked about this during a lunch I went to with Brent Huston (web, twitter) and he asked me had I done a write up on this ... and I haven't so I shall.  It's a good piece of info that I think everyone should master - Ask the right question, get the right answer.  This pays off in so many ways, it isn't funny and you can use it and abuse it everywhere, in everyday life.  This isn't a great theory that doesn't work in reality, this is a basic foundational requirement.  Yes, I feel very strongly about this and Brent suggested I should write up how I managed to teach it so here goes.

I hinted at this when I mentioned a good friend of mine, Jay Saunders, was graduating.  I tortured him for a solid 2 months (probably more), teaching him this practice.  When he started, I told him the number one thing was teaching him how to ask the right questions.  Purpose being is multi-layered.  First, without asking the right questions, you waste a lot of time figuring out what they (the users) really mean.  Second, if you take a minute to think about what you really want, you also should think of the possible reactions of the person being asked -- I will come back to this because there's a lot of nasty pitfalls that need to be addressed.  Third, it forces a different thought process and finally, the real goal, it forces the person being asked to NOT give a wrong answer. More...

Start the discussion

This is a continuation of my mentoring post made a few days ago but on a more fundamental level.  I have no doubt that within every organization, every team and their members are thinking the same thing, but no one is saying it.  There's a lot of reasons why and none of them are good.  So what's the problem?  Communication.  People are afraid of looking stupid, asking a dumb question and generally don't want to look like the guy that doesn't know.  Well, I usually don't know, so I ask and I've noticed a trend that doesn't surprise me - discussions begin to spawn awesomeness but they're not happening everywhere.

A perfect example came around a few weeks back.  I got some time to sit back and learn something so I asked Jon Kruger about what I should be learning next?  It's a huge, open ended question but he had a quick, exact response - learn TDD.  He didn't say read up on silverlight or ruby or any thing else, he went right for a practice that he's using, regardless of its language.  Ok, great, so I asked him "point me in a direction" ... he didn't find anything that was particularly good so, bonus, it spawned a lot of discussions and a few blog posts ...

TDD Starter Kit - Sample Projects and Links

What should you learn next?

Even more important, he did a Lunch and Learn -- we had a full house, around 60 people showed up.  That's a great turn out and even better for Jon (people need to listen to him) but when I left I noticed yet another issue ... a group of people, 5 of them were discussing among themselves how they didn't understand where his mocking came from and how his structure map was working because "it was a custom written thing".  The fail was simple : They didn't ask.  If they would've went up and started talking to Jon about it, I'm sure Jon would have tore it apart and showed them anything and everything -- maybe even wrote a supplement post on it.  But they didn't and the general take away was "I don't know how this part works, so I don't need it".  Again, this is the fear of asking stupid questions in it's perfect sense.

So what's my point?  Start the discussion.  Take a chance, ask and find out.  The excuse of being silent and pretending "I get it" doesn't apply if you sit back and don't ask.  The biggest result that can happen is a wide, sweeping discussion that hashes out a ton of stuff that no one knew everything else is thinking.

Rolling off the Net Admin - 12 lessons learned

My past rash of posts have mostly focused on hardware, servers, linux and other related devices and I'm glad to say, I'm heading back into development.  Granted, its VB but its development.  So what have I learned in my nearly 6 month absence?  Quite a few things, some of which will change my approach on a variety of things. More...

Production Outage Planning - 10 (or so) points

I've recently went through a number of production planned outages of a group of systems we've recently taken over. I like these outages because of that magical word planned. This isn't planned like you put it in your planner and write down a time, no this is a concrete list with no surprises, no unclear roles, everything is laid out and everyone knows what they are doing. This doesn't seem hard and it really isn't, just takes some attention. Being my 2nd or 3rd one on this current project and I'm noticing some good stuff and possible fail routes that can easily be avoided. More...