Generally, in some way, the story involves the evil boss meme. “It’s not my fault”, and so on. Personally, I’ve never really experienced the evil boss. Even if the boss does require overtime, the boss can’t be everywhere, all the time. People sneak off for long lunches, come in late, surf the web, and otherwise do things to take relief during the work week.
No, today I am going to talk about a more insidious kind of burnout: The kind we do to ourselves. Continued »
WWDC is happening right now. June 2nd through 6th your tech news feed will be barraged all things Apple. That isn’t much different from normal though, right? There seems to be a slightly different version of the iPhone every few months now. While the conference has just begun, there is plenty of stuff to talk about. A couple things are apparent: Steve Jobs is no longer with us, the keynotes so far have been lack luster, and the audience doesn’t seem all that into it like they have been in the past. Still, there are a few big announcements.
Now imagine the conference you want to go to is in a foreign country. Perhaps the conference itself is in english, at a five star hotel — but once you leave the building, the average person speaks about as much English as you do Spanish. (Which is to say, not much.)
That is exactly what happened to me this week, as I flew to ExpoQA in Madrid, Spain. Actually, it was a bit more challenging: Half the conference sessions were in Spanish, and about half the audience in my session word headphones and only understood me in Spanish.
Along the way, I learned a few pointers I thought you might like to hear before you get in that plane to another country. Continued »
A couple months ago I wrote about a few options for people interested in tech education outside of a university environment. I recently took a 3 day course online from James Bach called RTIOnline. The purpose of this class is to develop practical skills for software testers at all levels. I am going to review the class as well as discuss a few reasons this style of education is significantly different from what I’ve talked about in previous articles.
Lets take a look…
That move is starting to look like a mistake after Rocky made a bizarre set of public tweets that insulted members of the management team.
On Monday, May 5th, the company fired Rocky, in a spectacular, public way.
Then things got weird. Continued »
TDD is dead!
Wait…what? The patron saint of Ruby on Rails wrote that post proclaiming the death of Test Driven Development and then outing himself as a non-practitioner of TDD. Lets step back for a minute real quick though.
What is TDD, anyway?
First, what is test driven development. TDD is style of software development where before writing functionality, you start by writing a little test. Only after writing a test, do you begin writing the code to satisfy that test. The goal is to develop a set of confirmatory tests that tell you that your code is doing what you think it is while you continue making changes. Another goal is to support the business by making software better and changes to software a little less risky.
I think what David is saying in his post is that TDD has become dogmatic. He suggests that it is used to the extent that software has become overly complicated at the expense of developing these tests and now doing this is the standard. Also, he suggests that real software testing has been sacrificed on this altar of confirmatory tests. Maybe he is right, but the hardline position is concerning. If DHH was only saying something along the lines of “TDD isn’t enough…”, I think we as a dev community get that without provocative blogging.
Dogma meet dogma
About 10 years ago when I got started in software testing I heard rumors of this new fangled style of development. The folks that knew about it were craftspeople by virtue of seeking out that kind knowledge. Those people actively thought about what they were doing. Realistically, these people were working in the fringes of software development culture, most didn’t and don’t bother with new techniques. Eventually, TDD worked its way through time and space and now TDD is almost a household name.
The commoditization of Agile, with a capital ‘a’, has nudged all of this along. In the current Agile world, development styles like TDD are mandatory, hiring an agile coach is a good thing,, scrum is part of your daily ritual like breakfast, and continuous delivery is the goal you shoot for.
I don’t recall any of that stuff in the agile manifesto, but there it is…
This is the sort of philosophy that is great for people selling training, and certifications, and packaged services, but it isn’t doing any favors for the software industry or the people paying for that software.
So, how does all of this effect the software biz?
My hunch is not all that much, and maybe a little on the net negative side. When people with a large audience come out and say something like this, people take it to heart rather than spending time investigating and experimenting to find their own truth. This means that whatever value and tribal knowledge was there, is disposed of without really thinking about situations where is really can solve business problems. Topics like this always make waves for a little bit and then maybe they latch on, or maybe they don’t.
My suggestion? Do what Lean suggests (smell that sweet irony!), find the value in your product and focus on that. Development fads come and go. Paying clients stick around for value, not cool test frameworks.
I use Skype for my business – to make outbound calls – and I pay a little for the privilege. It’s not much; an annual subscription of ten dollars so. Still, when I got this in my inbox, I was a little distressed:
After reading the email twice, I realized that payment was auto-renewed annual, and the expiration date on my old physical card was about to expire, even though the merchant had sent me a new card weeks ago.
So I logged into skype and tried to fix things, which is when things began to fall apart. Continued »
Matt recently wrote a piece on how he predicts flow using yesterdays weather. This is a way to figure out how much work you will do tomorrow based on how much work you got done yesterday. Today I’d like to talk about how you might get a more accurate look at the weather using inventory control techniques.
Earlier in the week I introduced the idea of #NoEstimates, suggesting that estimates are not essential on technical projects and it could be possible to run projects without them. For example: early in my own career, I was assigned to a business unit for three months of work. The specific scope of work changed so often that instead of trying to do the original project, we split the work into index-card sized stories (at left), then had the customer order the cards. I met with the customer weekly, showed what was done, and allowed the customer to add new cards, change the priority, and, occasionally, tear them up.
Here’s the amazing thing: After two and a half months, the customer looked at what was left and agreed these things had low value. The project was done early!
Then again that was a single programmer for three months. Can #NoEstimates be done with multiple teams, on multiple projects? At the program and portfolio level? If so, how?
I believe the answers are “Yes”, “Yes”, “Yes”, and “Let’s Talk.” Continued »
This blog post is for you. Continued »