It was a short trip; in Tuesday, out Thursday. See a client, work out of their office a bit, go to a user group meetup, head home. You’d think, by now, I would have this down pat.
In some ways I did. All my tech and clothes in one backpack, fast-on off shoes, a lightweight coat with all my things so nothing would be in my pants pockets for security. The flight was out of Kalamazoo Michigan at 7:00AM, an easy half-hour drive for me with great parking and fast security. My things were by the door to go out, the alarm set for 5:00AM. Assuming 15 minutes to dress, I could be at the airport by 6:00 with plenty of time to spare; my mind even work me up at 4:55 to turn off the alarm without waking anyone up.
Then things fell apart. Continued »
It seems like I’m starting a software testing meetup in Nashville.
There is a Slack group for software developers in the area that has channels, one of which is dedicated to testers. A few of the regulars decided we should get together to have a cup or two of coffee together, and hang out and talk shop. That was probably a year ago. We had a second meet in January of this year, and then another one just happened. And, now people are thinking about March.
There was no grand plan for getting a new event going, it just ‘sort of happened’. I think I understand the how and why, if you are interested in meetups or want to build one yourself, this is for you.
Automation is here for good in software development, and it will have big affects on how we work. But not in the way you might think.
In 1779 a man names Ned Ludd got tired with mechanization and industrialization reducing the number of jobs available for skilled craftspeople. Ned led a group of people in what he called ‘machine breaking’, sabotaging the machines in hopes that it would stall progress from industrialization. They broke a few machines, but couldn’t keep up with the pace that they were being made. These people eventually became known as the Luddites.
Automation and using machines isn’t going anywhere for the software industry either. If anything, it is on a rapid upswing right now. Let’s take a look at the unintended side effects of this trend.
Agile has never been anything more than a set of guiding principles. That is both a blessing and a curse. Teams that are trying out something new have very little guidance on where to go without an experienced person to give guidance. Others that have been ‘doing agile’ for some time see deviating from the popular frameworks and practices (TDD, BDD, KanBan, Scrum, automate all the things) as being less agile.
If you missed part 1, where I introduced Andy and the GROWS method, you can find that here.
As an employee, I never had enough time to do everything. When you think about it, that sort of made sense; management wanted to wring every drop of value out of me. If I was working on four things at the same time and could meet my deadlines, why not assign Matt a fifth?
That was a long time ago, back when projects worked in big batches, and you would “juggle” projects, with one that needed serious attention to code while another needed less in test and a third even less in requirements. I understood the thinking, and figured once I started my own business, then things would be different.
Then I started running my own business, and things got worse.
Let’s talk about why that is, and what to do about it.
Agile started out as rebellion. A group of people who were tired of the routine, structure, and lack of flexibility in software development got together in Snowbird and decided to do something different. Some might say that agile is now that routine, structured, ‘do this, not that’ software methodology that some were rebelling against in the 90s. Andy Hunt is one of those people, and he is doing something about it with a new method he is calling GROWS.
Andy was kind enough to talk with me about GROWS, his experience with agile, and what differentiates his new method from everything else.
Let’s get started.
Princeton University led by Andrew Appel just received a 10 million dollar grant from the National Science Foundation to explore tools and processes to completely eliminate the software bug. The basic idea is that all bugs originate from differences between the software specification, and how the code is written. The researchers hope to do all this through a tool called DeepSpec.
The premise of this research is a scam, anyone with a few years of experience in software could tell you that. That is a pretty hard statement, let me explain.
– Every career advice answer to a forum question on the internet, ever
Okay, maybe not ever, but this is the standard advice to any problem at work. On the surface, it certainly seems reasonable. Perhaps a bit obvious, the core of this message is: You’re gonna have to do something.
Here at Uncharted Waters, we take a second look at conventional wisdom, putting it to the dark room test. That is, if instead of listening to that one-hour presentation (or reading that ten-page forum post) if we just sat in a dark room to think, could we come up with answers as good or better? Sometimes the answer is ‘no.’
Sometimes it’s yes.
Today I’d like to take a look at one piece of the conventional advice answer: FU Money, how the pursuit of it could actually be holding you back, and something better. Continued »
I love holiday travel. The airports are overcrowded, planes are running late, and families are trying to round everyone up to the right place at the right time so they can get back home. It is basically the perfect environment for noticing something out of the ordinary. I’m a (mostly) loyal SouthWest customer. They have good customer service, and reasonable rates. On my flight last week, I also happened to notice that they take kaizen seriously.
Kaizen is a word we took from the Japanese invention of Lean process after World War 2. There are different interpretations, and methods that may or may not be mandatory depending on who you talk to, but the most important part is experimentation and discovering what can be done better.
Lets take a look at an example of how SouthWest changes things and aims for efficiency.
It’s performance review season.
The temperature outside has been steadily dropping for a month now. Unless you’re in California or Florida, you probably have to let the car run for a minute to melt off ice on the windshield. Instead of having a few more hours of sunlight each day at the end of work, it’s pitch black and may as well be midnight.
You know that that means, and it isn’t a signal for Santa’s arrival.
Everyone hates them. For managers it is a month long time suck of paperwork, dividing up a shrinking budget, and reviewing work that may have happened 9 or 10 months ago. For employees, it’s a time to strategically talk about the work you did. You want to give an honest review, but not so much that you kill your chances of getting more money for the next year.
How do you turn the yearly performance review into something that works for, instead of against you.