EppsNet Archive: Software Development

Antipattern: Daily Standup is Too Long

19 Jun 2014 /

Scrum recommends timeboxing daily standup meetings at 15 minutes. If you can’t finish in 15 minutes, there may be something wrong with your format.

Are you actually standing up? What are you talking about? Each person should answer three questions:

  1. What have you accomplished since the last meeting?
  2. What do you plan to accomplish between now and the next meeting?
  3. What, if anything, is impeding your progress?

Focus on accomplishments, not just assigned tasks, i.e., don’t say “I’m working on A and I’m planning to work on B.” Don’t have discussions. Anything coming out at the meeting that needs to be discussed can be discussed after the meeting. Try saying this more often: Let’s talk about that after the meeting. Immediately after the meeting if necessary, without even leaving the room, but not during the meeting.

Anyone in the meeting who is not responsible for accomplishing things during the sprint should not be talking.

Are you clicking through a project management tool to review what each team member is working on? Don’t do that. Anyone who wants or needs that information can click through the project management tool on their own time. Talk about accomplishments and blockers.

Why is this important? Well, you can meet or you can work, but you can’t meet and work at the same time. I recently observed a daily standup with 20 attendees (including remote workers) that was running 30 minutes a day, i.e., 15 minutes too long. They were losing 300 minutes per day (15 minutes x 20 people), 25 hours a week, and 100 hours per 4-week sprint.

Do the math on your own standups and decide if it’s important to you.

Thus spoke The Programmer.


Hard Deadlines

7 Jun 2014 /
Alarm Clock 3

Does saying “This task has to be done by Friday” increase the chances that the task will be done by Friday?

No, but it increases the chance that it won’t be done before Friday.

Better question: Why isn’t it done now?

Thus spoke The Programmer.


Risk = Cumulative Cost – Cumulative Value

9 Mar 2014 /

Henrik Kniberg has a presentation online called “What is Agile?” It includes a method of visualizing risk as the gap between cumulative cost and cumulative value, as well as methods of visualizing risk mitigation strategies.

I found it valuable. Here are some representative slides:

Big Bang = Big Risk

Agile = Iterative + Incremental

Improving the Value Curve


9 Links

1 Mar 2014 /
  1. Data Structure Visualizations
  2. Good Tech Lead, Bad Tech Lead
  3. Google Java Style
  4. Guide to 12 Disruptive Technologies
  5. How to Write a Cover Letter
  6. The Landing Page Optimization Guide You Wish You Always Had
  7. Selendroid: Selenium for Android
  8. UX Axioms by Eric Dahl
  9. Yelp’s got style (and the guide to back it up)

All Projects Should Be Early

12 Dec 2013 /

From a Jeff Sutherland Scrum deck:

All projects should be early

You can maximize the value delivered per unit of time or cost by shipping when the value curve starts to flatten out.


Passing the Cloudera Hadoop Certification Exam

9 Dec 2013 /
Hadoop

Today I took and passed the Cloudera Certified Developer for Apache Hadoop (CCDH) exam. Two resources were helpful to me in this successful endeavor:

  1. Hadoop: The Definitive Guide by Tom White
  2. The Cloudera practice test, which I found much harder than the actual exam.

Fast Work

17 Nov 2013 /

A junior high school math teacher posted this on Facebook:

math-test

That makes perfect sense to me. Work gets done a lot faster if the results don’t have to be correct.

Thus spoke The Programmer.


Certifications

9 Aug 2013 /


Software Estimation Options

8 Aug 2013 /


InfoWorld: In most areas associated with productivity, U.S.-based staff exceeded offshore staff by wide margins . . .

Posted by on 6 Aug 2013

Minimizing Retention

4 Aug 2013 /

From an actual job description for a Software Development Manager:

  • Worth with management and directs to put together a solid SW Development career development plan in alignment with Organization Solutions all-up to grow hi-potential employees and minimize retention.

If you’re writing job descriptions and learning English at the same time, there’s no shame in having a native speaker review your work.

The job description goes on like that for 10 or 12 more bullet points. I singled that one out because I like the phrase “minimize retention.” I can recommend a couple of people for that.

I assume it’s a language problem in this case — that the author meant to say “maximize retention” or “minimize turnover” — but it might be a kick to have a job where your actual charter is to minimize retention.

You would not be an easy person to work for. You would take all the credit. Your subordinates would get all of the blame.

Picture having the names of all staff members written on a whiteboard in your office and removing them one by one with a triumphant swipe of your eraser at the end of their (hopefully brief) tenure.

Maybe your boss would stop by every now and again to tap on a name and ask, “Why is that guy still here?”

Of course, if some clinging vine is screwing up your retention rate by refusing to quit (maybe he really needs the job?), you can just call him in and fire him. Or her.

Good times! If only all job objectives were this easy to meet.

Thus spoke The Programmer.


Amateur Design

3 Aug 2013 /

The worst scenario I can imagine is when we allow real customers, users, and our own salespeople to dictate “functions and features” to the developers, carefully disguised as “customer requirements.” Maybe conveyed by our Product Owners. If you go slightly below the surface, of these false “requirements” (“means,” not “ends”), you will immediately find that they are not really requirements. They are really bad amateur design, for the “real” requirements — implied but not well defined.


Agile, ALM, and Agile 2.0 — Putting the Cart Before the Horse?

1 Aug 2013 /
Cart before horse

Speaking of selling chickens still in shells, an august panel of industry giants laid out their recent improvements and plans for ALM products (Application Lifecycle Management, for those not in the know). These guys dazzled the audience with how they’ve moved far beyond simple source code repositories and testing tools to a complete integration of all modern software practices. Quite a coup, indeed, since most real live software developers I’m seeing out there today still aren’t using the practices automated by the ALM tools. . . .

In other words, many software developers aren’t using practices such as test driven development or source version control. Yet here are HP, Microsoft, and IBM announcing new ALM tools that automate more advanced practice in areas not even in use in the first place. Unbelievable.


Seamless Integration

16 Apr 2013 /
Seaming

(Photo credit: The Bees)

There’s an unwritten rule in the software business that any integration between two systems must be described as “seamless,” the result being that the word no longer has any meaning.

My favorite seamless integration storyline took place years ago when IBM had a joint marketing pact with Vignette, and offered “seamless integration” between the WebSphere application server and the Vignette content management system. In fact, the two systems weren’t integrated at all by any definition of the word “integrated” that I know about. We had to write our own interfaces to move data between them.

The funny thing is, that is seamless integration if you think about it, in that there’s no seam between two things that are not connected at all.

For example, my shirt neatly integrates sleeves, cuffs, pocket, collar . . . but not seamlessly. There are seams all over the place. Whereas the shirt is seamlessly integrated with my pants. I can stuff the shirt in there and if I don’t move around too vigorously, it will stay there and not come out.

What’s so bad about seams, anyway?


Every New Feature is a New Failure Point

14 Apr 2013 /

The TPMS warning light on my car dashboard is lit up, which, according to the owner’s manual, indicates a malfunction in the Tire Pressure Monitoring System, a system designed to alert me, via a different warning light, when the tire pressure gets too low.

It’s a completely unnecessary system to begin with because I can monitor the tire pressure myself, as drivers have done since the invention of the automobile.

Let’s add a completely unnecessary new system so when it breaks, the owner will have to pay to fix it.

Can I just ignore the warning light? I don’t know. The worst-case scenario is that the TPMS not only breaks but creates a domino effect that knocks out a critical system that I actually need.

Toilers in software development can draw their own analogies . . .

Thus spoke The Programmer.


Ron Jeffries: Estimation is Evil

Posted by on 16 Mar 2013

Engineering Humor

9 Mar 2013 /
Root beer

An engineer walks into a bar and orders 1.0E20 root beers.

Bartender: “That’s a root beer float.”

Engineer: “Make it a double.”

[HT: Scott Hanselman]


Generalists Are Better Than Specialists

9 Mar 2013 /
Halo Reach, Forklift.

People ask me what is my “specialty” in software development. My specialty, if I have one, is in not having a specialty. I feel like I can contribute on any task.

That answer throws people off. They repeat the question, explaining that everyone is best at something. Managers especially like the idea of specialists because it simplifies the assignment of work: UI tasks go to the UI guys (or gals), SQL tasks go to the SQL guys, middle-tier tasks go to the middle-tier guys, and so on.

Before launching my illustrious career in software development, I worked on a union construction site. Everyone’s job was defined in excruciating detail — what each union member could and couldn’t do.

For example, if we needed to move a pallet from here to there, we had to find a teamster to drive the forklift. There were a few exceptions to that rule, depending on what was sitting on the pallet. In the exceptional cases, we had to find an operator to drive the forklift.

If we couldn’t find a teamster or an operator, the pallet had to sit where it was. We couldn’t move it. It didn’t matter how many other guys were standing around who knew how to drive a forklift.

Since then, I haven’t been a fan of specialization on work teams. It leads to some people having more work than they can possibly do while other people are standing around idle.

I’d make an exception if work demand could be guaranteed to match the available allocation of specialists (i.e., never), but if not, then give me a team of generalists every time.

Thus spoke The Programmer.


Victor Szalvay: Technical Debt for PMs

Posted by on 5 Mar 2013

There is a Difference

17 Feb 2013 /

There’s a difference between being persistent and floundering.

Thus spoke The Programmer.


Next Page »