You’ve likely heard the term “boundaries” used before – perhaps to describe a nosy uncle who “has no boundaries.” Or perhaps it is to deal with a bad boss or colleague. “You need to have better boundaries”, they say, as if this magic word can fix everything.
Even worse, boundaries are shallow words. The type of word that everyone seems to understand instinctively, yet asked to defined says “You know, shallow_word.” If you press on for a definition, you are the weird one.
Today I am going to talk about boundaries at work, what that means, how to implement them, and how they help you. You’ll leave able to explain boundaries to others, defend yours well, and most importantly, how that can transform your work life. Continued »
It’s been a rough decade for interviewers.
First, we found out that the classic way of hiring a juggler, of asking them where they went to school without asking them to juggle, wasn’t so great. Instead, it might be better to do a skills-based interview. We rejected “gotcha” questions like “why are manhole covers round” because they demonstrate “aha!” and might not correlate to job performance.
Then we found out that FizzBuzz, the common technical interview, was terrible.
Google popularized the algorithms-based interview, where programmers create trees or hashes or sort routines. I even interviewed at Google myself, and wrote about it. Eventually the community ripped Google’s approach was not what programmers actually do all day. Many reject the whiteboard or keyboard-driving interview as too much pressure.
Of course, many other people will reject the take-home job interview, as it is basically extra, unpaid-work.
We learned that programming katas have bias, but can work to reduce that bias.
Finally, I see a comment that language-gotcha questions are bad. Over the years, I have learned a few questions I like. I post one of them. Of course, it is terrible.
Apparently everything is terrible and now I’m one of the bad guys.
What is going on here?
It’s been ten years since I read “Big Agile Up Front” on the C2 wiki. That article describes an “enterprise” where team members who have to go through a “deployment” routine in order to get a unit test to ru. They hook up their continuous integration server to an “Agile” Gant chart which control ever change and reject the “planning game” as unprofessional. (“Game? This is no game!”)
At every step, the decision seem right. They are “Enterprise-y.” Grown up. Mature.
Yet every single step slows down delivery. It robs the place of joy. Somehow it takes nine months to get anything done.
What is happening here? Continued »
Earlier in the week I wrote a post, Why Johnny Can’t Agile. The post made a point that we might consider giving up on “saving” legacy code bases. That is, code without unit tests, with a high change failure rate, where a change in one place might break another. Perhaps it is all just too hard, and we should all give up. My arguments were strong, stirring, compelling. And wrong.
To be fair, I had data. Over the past few years I’ve worked with a dozen organizations, and interviewed or been “near to” a few dozen more. Many of them do big public presentations about their agile adoptions. When I visit, they invariably have sprints, stories, and standups. The work may be sliced thinly – perhaps too thinly. I see stories like “a new etr to the table” that could be written as “create a single INSERT statement in a database that is essentially a cut and paste.” Everything seems to take a long time. There is not much joy. The magical feedback and improvement loops that inspired the title of Jeff Sutherland’s book Twice The Work In Half The Time — those simply do not happen. In my previous piece, I called a real agile adoption “next to impossible.” This was my working hypothesis:
I’m starting to wonder if we should say “legacy systems should be managed differently than greenfield development. Count the cost. You may come to different conclusions.”
It was Lisa Crispin, one of my peer reviews, that pushed back strongly on this. After all, she had been on companies that had broken through (as had I), more than a few times. If I wanted to give up on saving legacy projects and teams (which is most of them), why the sudden change of heart?
After the new year I wrote this article, then asked for a few rounds of peer review. My reviewers, including Lisa, pointed out that I was wrong. Or, perhaps more politely, they pointed out I could benefit from a different perspective. I decided that I was wrong. Instead of changing things, I decided to present the original post, as-was, and ask for your feedback, before presenting some corrections. Assuming forewarned is forearmed, there you go. Tell me how I am wrong.
Because I am.
I was talking to Lisa Crispin earlier today about the state of devops survey. That survey identifies four levels of “performers.” For performance measures it looks at how long it takes a change to get to production after commit, how frequently new code goes to production, or the percentage at which a change “fails”, creating new problems. These measures are more concrete and “hard.” They are easier to measure, but don’t include all the concepts in Agile software. Collaboration, for example, is remarkably hard to measure. Still, we’d tend to call the companies that are high achievers on the DevOps survey “Agile.”
For some reason, it is next to impossible for established organizations to get there. Continued »
Mis-classifying in-fact employees as independent contractors is not new. What is new is California’s law, AB5, which strictly defines the independent contractor role. According to the Washington Post, AB5 is “aimed at Uber and Lyft.”
Except, of course, Uber is saying the law does not apply to them.
It seems like something out of a science fiction Novel.
Let’s break it down, and what it means for software. Continued »
John Cuttler just put up a common conversation on twitter. That is, the “no matter what you are wrong” conversation with management. John’s example starts with management asking what the problems are. The team takes time to create the three hundred tickets to address the technical problems. After a long delay, management says they can allow the team to spend 8% of their time to fix the issues.
The conversation death-spirals.
It’s a good thirty-second read; check it out for yourself.
This problem is so universal. It connects to my own experience — repeated experience. John says the “sad cycle” is “so predictable.” Jeff Kosciejew proclaims “I’ve worked at this company!” How is it possible the same terrible conversation has happened to all of us?
Last time I talked about the people-people with the soft skills that had taken over Agile Software Development. It is easy to dismiss them as the “hippies with the flip-flops and the love beads.”
Yet they have taken over.
What, exactly, are soft skills anyway?
How can they be so magically powerful that the people-people always “win”?
Today I’d like to take a hard look at soft skills – and why they matter in business. Continued »
The growth rate of the software field in the USA means that more than half the people have less than ten years of experience. Meanwhile, Scrum has been established as the default way of doing software for about ten years. Combine these facts and you get one stark reality: The majority of people in software today have spent their entire careers in a world where Scrum was “how we do it” and waterfall was “old and busted.” It seems that on a daily basis I am told that “Agile” is bad and “sucking the life” out of team members. We have forgotten our Agile History.
This is a pattern. I’ve seen it before.
And, with a little Agile History Lesson, we can stop it from happening again. Continued »
Twelve years ago I was complaining about this term, Heuristics. The term itself is incredibly simple in meaning – the kind of thing you can learn in thirty seconds. People seemed, to me, to be using it to “sound smart”, to create insiders (who knew the term) and outsiders (who did not).
Today I see the value in it – the term is precise. I want to bring you on the inside.
Let’s start with that thirty second definition.
“Attend to what you eat, how you sleep, and exercise” won’t solve every weight problem. You could have an insulin problem or other medical condition. Yet it is good enough, often enough, that it is a go-to idea for us. The engineering term for an imperfect way to solve a problem is a heuristic.
Many of us have our heuristics internalized. They are implied in the way we work, and can be as simple as “if you want to get anything done for the day, don’t start with email. Start by doing the work”, followed by “at the end the the day, park your work to start it immediately tomorrow.” Those are productivity Heuristics. (By the way, it is prounounced “Hew-Ris-tic”) Today I want to talk about my heuristics in software testing.