Don’t kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%. Most likely, that means going from 0% to 1%. And that’s the biggest improvement of all. — 8 ways to be a better programmer in 6 minutes Read more →
EppsNet Archive: Software Development
The Game Blame Game
My boy is playing NBA 2K12 and points out that my Where’s Waldo shirt looks like the Washington Wizards (nee Bullets) throwback uniforms. “Where’s John Wall-do?” he says. Ha ha. I get my comeback opportunity a few minutes later when his game player passes to a teammate, who scores, but his player doesn’t get credit for an ssist. “HOW CAN THAT BE ANYTHING BUT AN ASSIST FOR ME?!” he shouts in disbelief. “That’s bad programming.” “Oh I doubt that,” I say. “The people who program video games are a lot smarter than the people who play them.” Read more →
Customer Discovery and Customer Validation
Ask yourself these questions: Do these users in your user stories exist and have you ever spoken to them? How are these features helping your customers achieve their goals? Are these benefits based on any quantitative or qualitative data? — The Product Owner’s Dilemma | Scrumology Read more →
Following Directions
I see the history of management as an effort to perfect the instructions that you hope someone will follow this time — even though they have never followed directions in their whole life. — Margaret Wheatley Read more →
Case Study: One Programmer is Better Than 80
When I was working at the Boeing Company in the mid-1980s, one project with about 80 programmers was at risk of missing a critical deadline. The project was critical to Boeing, and so they moved most of the 80 people off that project and brought in one guy who finished all the coding and delivered the software on time. I didn’t work on that project, and I didn’t know the guy, but I heard the story from someone I trusted, and it struck me as credible. — Steve McConnell, Making Software: What Really Works, and Why We Believe It Read more →
Aside
David Anderson: Lean Kanban Southern Europe 2012 keynote
Ruby on Rails for Rubes
The biggest headache in software development is that most programmers can’t program and don’t want to learn anything. I recently finished up a MOOC called Software Engineering for SaaS, offered by UC Berkeley through Coursera. For a modest investment of a few hours a week for five weeks, I learned some Ruby on Rails — a well-designed platform and a lot of fun to work with — as well as tools like GitHub, Cucumber, RSpec, SimpleCov and Heroku. Over 50,000 students from 150 countries signed up for the class. According to a final email from the professors, about 10,000 students attempted at least one assignment or quiz. Or to look at another way, 80 percent of the students gave up without even trying. Approximately 2,000 students, or 4 percent, completed all four of the assignments and the three quizzes. One of the enrollees who gave up without trying is a… Read more →
Mobile Site vs. Full Site
From Jakob Nielsen’s Alertbox: The basic ideas are to: cut features cut content enlarge interface elements Read more →
It’s Always a People Problem
Even when it’s “really” a technical problem, it can always be traced back to management action or inaction. Even so, the experienced consultant will resist pointing out that it was management who hired all the technical people and is responsible for their development. At the same time, the consultant will look for the people who should have prevented this problem, or dealt with it when it arose. — Gerald M. Weinberg, The Secrets of Consulting Read more →
Which is More Valuable: Collaboration or Competence?
The title of this post makes a good interview question. Usually, the candidate will say something to the effect of “they’re both valuable” to avoid the possibility of slipping up and choosing the one that the interviewer believes is less valuable. Let’s say we need to get a picture painted. We could say, “Picasso — you’re our best guy in this area. We’d like you to paint the picture for us.” Or we could say, “Picasso — work with the steering committee to get that picture painted.” You could make a case for either approach, but you can’t do both. So which is more valuable? Personally, I think collaboration is overrated. It leads to the knowledge of experts and novices being given equal weight. There’s a reason why pilots don’t invite passengers into the cockpit to get their opinions on how to fly the plane . . . Thus spoke The Programmer. Read more →
Basically Done
One of our contract programmers tells me that his current project is “basically done.” “It’s done or it’s basically done?” I ask. “It’s done. Amanda is testing it.” “How do you know it’s done if she’s still testing it?” “All the tickets are closed except one, so it’s basically done.” “I don’t mean to give you a hard time. I’m trying to figure out if there’s a difference between ‘basically done’ and ‘done.’ Because usually there is. I inherited a project here last year that when I got it, it was ‘basically done,’ except it needed some more testing. I put one of my best guys on it and he was still working on it a year later when it was finally cancelled. It took a year to go from ‘basically done’ to cancelled. Hence my lack of fondness for hearing projects described as ‘basically done.’” Notes for next team… Read more →
Misled by Metrics
From a Sr. IT Consultant: I recently asked a colleague [CIO] whether he would prefer to deliver a project somewhat late and over-budget but rich with business benefits or one that is on time and under budget but of scant value to the business. He thought it was a tough call, and then went for the on-time scenario. Delivering on time and within budget is part of his IT department’s performance metrics. Chasing after the elusive business value, over which he thought he had little control anyway, is not. Read more →
Aside
Jeff Sutherland: Scrum: Why Story Points Are Better Than Hours
Growing a System
Some years ago, Harlan Mills proposed that any software system should be grown by incremental development. That is, the system first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below. . . . Nothing in the past decade has so radically changed my own practice, and its effectiveness. . . . One always has, at every stage, in the process, a working system. I find that teams can grow much more complex entities in four months than they can build. — Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering” Read more →
The Essence of Scrum
Good short article by Tobias Mayer on the principles of empiricism, emergence and self-organization, and the mechanisms of prioritization and timeboxing. Read more →
Aside
Agile Training: The Four Levels of Agile Requirements
Craftsmanship over Crap. — Uncle Bob
INVEST in Good Stories
What are the characteristics of a good user story? Bill Wake developed the INVEST acronym: I – Independent N – Negotiable V – Valuable E – Estimable S – Small T – Testable For a short description of each attribute, see Wake’s excellent article. Read more →
Things Which Matter Most
Things which matter most must never be at the mercy of things which matter least. — Goethe You’ve got to keep your priorities in order . . . We’re developing an on-site conference registration system . . . the topic generating the most email bandwidth yesterday was the ability to retry a declined credit card if the on-site Internet connection is down. Declining a credit card when the Internet is down is an unusual scenario that may never occur. We’re not even far enough along in development to be able to say for sure that we can accept a credit card when the Internet is up, but by golly, we’ll be able to decline one when it’s down. My head is spinning . . . Thus spoke The Programmer. Read more →
Aside
Signal vs. Noise: A shorthand for designing UI flows