DHH (aka David Heinemeier Hansson, the creator of Ruby on Rails) wrote a blog post in the last week about the value of human exploratory testing. Usage of tools to make software development more sustainable has taken a massive leap in the last 5 years. There are all manner of programming frameworks and APIs available, most for free, to help people test code. There has also been a deluge of build and deploy tooling that helps us move from code to a running, testable environment in a matter of minutes or less.
That tooling created a mind shift (or maybe the mind shift created the tooling?) leading part of the dev world to think that they could build smaller, test more granular via tooling, and get away without much of what we call exploratory interaction. This has worked in some domains, but not so well in others. The testers reading this are screaming “I told you so”.
DHH’s post is short, and short on details, but it is important because he wrote it. Development trends seem happen in a pendulum and this might be the beginning of a shift back.
Software development fads come and go every few years, and each time a new trend comes in something is demonized as waste. This time around, it is unit tests.
I was recently pointed toward a summary article explaining why most unit testing is waste. This text mentioned the common reasons for not testing — only tests derived from business requirements have value, too many tests slow development, tests have cost in terms of run time and maintenance, and the idea that tests don’t improve quality. Some of these points seem reasonable, and maybe obvious, but I don’t think they mean unit testing is waste.
An acquaintance on Twitter brought up an analogy in vaccination that I want to talk about briefly.
When people create project plans, requirements, and other documents they often use a template. A template makes things easy. The author can fill in the project name, the date, who they are, the stakeholders, the technical team, the dependencies and the risks. At some point the author has to fill out the big box in the middle about what to actually do, but it’s easy enough to put in some fluff and click save. It’s even easier with tracking tools like Jira, LeanKit, or Pivotal tracker. No writing skills required.
Except we all know they are required. Describing what to build or how to build it, and communicating in a way that the other party actually gets is a skill. It can be done better or worse. Verbal communications is a skill, too, but that’s a different post.
Today I’d like to write about writing, with a few quick wins to develop writing skills. Continued »
Company building is hard. You have to decide what you want to sell and hope there is a market of customers out there large enough to make the money you want. There are the internal decisions of deciding how to build the product, figuring out who the right people to build it are, oh and how to pay for everything. Most companies aren’t making money right away, or even for a few years, so there needs to be enough financial support around the business to pay employees.
Venture Capital companies, or VC, help create that financial padding. They also act as a growth catalyst by pumping a bunch of money and some new goals into a company. Those new goals according to this article, and a story I want to tell, can kill a company.
Most of the people reading this will be familiar with the idea of “management by butt in seat time.” That’s where the manager cares when the workers get into the office, how long their lunch hour is, when they go home, and how long they spend at the water cooler or in the rest room. That’s not exactly the best way to manage knowledge work.
Indeed, you’ve given a little rant at the water-cooler, or, if you are less safe, in the car on the way home, on how terrible a practice this is.
But what can we do instead?
Let’s talk about a better way to manage knowledge work. Continued »
If you haven’t heard the term froo-froo coaching, you may have heard it referenced as something like “The gurus with the love beads and sandals singing kum-bay-yah around the campfire” or perhaps heard their work referred to as “hippy-dippy bullstuff.”
If you’ve heard terms like “energy work”, “creating a container”, “the power of intention”, “holding space”, asked what they meant and been frustrated, or not even bothered, choosing to walk away, then I wrote this post for you. Continued »
Process improvement in software teams seems harder to come by, and sometimes stops altogether, after the first few tries.
We see the exact same phenomenon in exercise. Take a person that has never done anything athletic in their life and introduce them to a barbell and a squat rack. For the first 2 or 3 months, they will be able to add 5 pounds to their squat twice a week. No problem. Toward the end of this progression, things get difficult and they have to play a mental game of pushing through something very difficult. Eventually, they just can’t put any more weight on the bar without reconsidering some things.
This exact same thing happens in software teams. And I think this is why the kaizen, or continuous improvement people, don’t see a whole lot of success.
I have been a pretty staunch opponent of certification in the past. I spent years working as an instructor for a program that dealt in hands on experience. To get through a class, students had to perform tasks, and then debrief on what they did and why with their peers. Assuming a student made it through the class, some did not, they were awarded a certificate to indicate they completed it. Not a certification of skill level.
I thought certifications were terrible. Worse than terrible. A student could buy a text book, or pirate the PDF version, spend a couple of weeks studying and memorizing and then take a test. After that person takes and passes the test, they get a new acronym to add to their resume. Something that indicates a level of skill. Something that sets them apart from other people that might be applying for a job.
I have changed my mind and want to talk about that for a second.
I have worked in offices for about half of my career, and from my home office for the other half. In the early 2000s, cubical farms were still very popular. I remember working at a company that had multiple floors of fairly well thought out cubical pods. They boasted that everyone in the company, up to the CEO, worked in a cubicle that you could walk by any time. The CEO was of course rarely in the building, but his cubicle was there if you wanted to see it. For posterity at least.
Today, many companies have flipped to open offices and boast productivity improvements. I suspect there is exactly zero data on the productivity change between offices with doors, or cubicle farms, or an open office, but there are plenty of anecdotes. Like most office process, open offices were designed for a particular time and place.
Is the concept still useful?
Six years as an independent, averaging a conference every-other month, with consulting assignments in-between. Four semesters teaching IS part-time, a couple years coaching soccer, and years of religious and military cadet education, I’ve learned few things about corporate training. Here are a few of my favorites – the easy, obvious things that yet are often overlooked.