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.
I spent most of my youth – and a good part of my 20’s – obsessed with things. As a mathematics major, then computer programmer, they were abstract things. You couldn’t even touch them. I worked with ideas. Christmas was something to put off until December 20th, then either guess, or, if I was lucky, work a list someone else gave me. The people in my life that mattered were close family. That is, if I remember them.
Eventually I realized the truth. Ten years from now, no one is going to remember if that project was on-time or a day late. What they will remember is how you made them feel. In IT, you can do better than 20% of people just by bothering to get a card for a few people that matter. Get to 10% by putting a lottery ticket into it.
If you prefer to think of life as a video game, consider this post about how to break above the top 5%.
This year, I’m going to do something unusual. Christmas gifts that won’t break the bank but can blow the doors off. At the end, I’ll review my more historic stocking stuffers, the kind you can get from Amazon for ten bucks that can lead to a great ice breaker.
This year, I want to do better. Continued »
A few days ago, I put out a post on twitter about Documentation.
That post was my most-replied-to, most-liked, most popular in weeks.
It’s time we talked about it.
For my brother’s birthday party, around age 5, my father rented some horses, kept by a farmer at the end of Route 40, which becomes West Patrick Street. The sides of Route40 were farm fields. During my early childhood I saw creative destruction as the fields were sold to create retail stores and restaurants — “The Golden Mile.” Behind the stores, more farms failed, and the suburbs came. More creative destruction. The central symbol of farm replacement was the Frederick Towne mall.
Today the mall sits locked and abandoned. It has become the Frederick Towne Ghost Mall. The retail shops and the suburbs behind them are failing. This is not demographics; it is not that the rich people moved away. Amazon, Ebay, and Wal*Mart.com make shopping in person dated, if not obsolete. Netflix and Amazon prime made it easier to watch movies than shlubbling down to a store to interact with (ewww) humans.
Commerce killed the farmers, then big box stores killed retail, then online shopping killed the commerce.
Karl Marx and Charles Darwin both observed the pattern, visible since the loom put a few hundred handloom workers out of work in 1788. The trade union that fought the hardest against automation-in-sewing were, no kidding, the actual luddites.
As you’ve probably figured out, they lost.
It was the Austrian, Joseph Schumpeter that gave a name to the pattern. He called it Creative Destruction.
Now think about the low-end worker, who could have been a farm hand in 1970 and worked retail in 1995. Where does that person work today?
Let’s talk about how Creative Destruction works. Continued »
Like it or not, resume inflation is a real problem in Information Technology. Those that are willing to lie a bit are rewarded with better jobs and more money. If you are honest, leaving terms off your resume because you do not know the tech, you might not even pass the keyword-match algorithm. More than one person told me that resume inflation is just expected. “People say what they need to say to get in the door”, goes the chorus “You use the interview to figure out who they really are.”
Which brings the next problem.
How exactly do you figure out who cuts the mustard?
Earlier I suggested we have a crisis of confidence in software development that is leading to a lemon market. My suggestion was an audition. The simplest audition for a programmer-type may be to ask them to solve the simplest of programming problems in a language they claim competence in. Personally, I am a fan of SQL. When you think about it, SQL is basically venn diagram converted into a grammar something between English and set theory from Mathematics.
They claim SQL on the resume. You ask a simple SQL question. Start with an employee and job table, which share a job_id in common. Write a query to find all the employees with a last name of “Smith” and their salary, which is in the job table.
I post it on twitter … and then things go sideways.