It's another conference I am attending. With that, hello again. I hope you will enjoy this live blog extravaganza that I do when I attend these conferences. A word of warning. These are stream-of-consciousness affairs. I do not pretend to do any great editing with these. They are my notes and impressions in the moment. If you choose to follow along as I write these, they are oftentimes disorganized and may appear very random. Realize, this is not me giving a blow-by-blow of the talk. Rather, it's what I'm thinking about as I am hearing the talk and how it may be relevant to me. Possibly, my musings may be relevant to you as well. Hey, here's hoping :).
I am enjoying these banner cards, they make for a nice encapsulation of the event and the person presenting. In this case, I get to hear from an old friend. I've known Huib now for over a decade and I enjoy hearing his presentation. He started the presentation with a poll asking about how we consider and look at our organization, how we communicate and how we actually deliver software. Many of the answers I could have gone either way and it seems that there are a handful of questions that are clear YES or NO, the results of the participants also seem to mirror my thoughts. Areas that I said a hard YES or NO to seem a lot of others did as well. I'm happy to see I'm not a huge outlier (LOL!). Also interesting to see that the areas I was "Ehhh, could go either way" also tended to be a 50/50 split.
At the core of these questions is the idea of speed vs effectiveness. Do we go faster because we are better at what we do or is the fact that we do good work consistently allowing us to move faster? I think there's a case to be made that both are true. To borrow from Adam Neely "Repetition legitimizes". That's a musical term but it also tends to be the case with software as well, we legitimize a lot of our actions and methods and the more legitimized they are, the better we feel about doing/using them. If we find that an approach doesn't work so well, we can likewise de-legitimize those processes and move away from them. To be clear, it is easier to legitimize new methods and processes than it is to de-legitimize an entrenched process. It's possible but inertia often works against us.
Huib makes the point that formula one car, while very fast, will likely not be very effective in the hands of a novice who doesn't know how to drive it (and before people comment, the mechanics of driving a vehicle are for the most part standard but I will not pretend that I will be able to drive a formula one race car the way a professional racer does. They trained to get that good and over time, they learned the tricks of the trade to be effective.
Likewise, just because we have amazing software tools doesn't mean that throwing tools at software problems and issues will effectively solve our problems. There is research, implementation, and practice. Yes, we as teams developing and releasing software have to practice to get good at what we do. As individuals, there is a lot that we can do but we do not operate in vacuums. We operate with flesh and blood people and those people will both help and hinder our efforts.
One of the key things to realize is that the speed of an organization (actually the speed of anything) is about 1/3 the responsibility of the infrastructure and 2/3 comes down to the behavior of the participants. A formula one race car might be an amazing machine but if I have a phobia of going fast, men behind the wheel might not be the best strategy (that's just for comparison's sake; to be honest I'm pretty cool at speed but realize I'd need the practice to be able to corner or evade effectively).
I've often felt this in the team I work on right now. Even though I have been with this team for over 18 months, I am by far "the newbie on the team". The level of knowledge the team has and the approaches taken to date are things that have been developed over the course of a decade and this crew has been together every bit as long. Thus, there is a level of understanding and training I perpetually need to be going through to hope to catch up with the rest of the team. Fortunately, I get a lot of help from my teammates and I learn something new every day, sometimes lots of things a day. One of the things we frequently do is to record sessions and conversations where we demo ideas and consider tools, processes, and methods of doing things. I have the ability to go back and review these sessions and really see what I know and understand. IT also gives me a chance to go back and see if my practice sessions are on track or focus on the things that matter.
Sometimes even with the learning, training, and practice, we also have to realize there is only so much gas in the tank and practically available refills (I'm going to drive this formula one metaphor into the ground... ba dum, tshhh ;) ). The point being, there's a balance that has to be maintained. We can only go so fast before quality suffers but also, there's only so much testing we can and should do and still be fast and effective.
No comments:
Post a Comment