EppsNet Archive: Software Development

My Name is Fido

3 Oct 2015 /

From an actual email:


My name is Fido and I’m an IT recruiter at TechDigital Corporation. We are currently hiring a .Net Developer/Software Engineer preferrably [sic] with experience in the Financial domain for a W2 or C2C Contract for one of our direct clients in Green Bay, WI.

Fido Xavier

  1. I live in California. Are there no software engineers in Wisconsin or anywhere between California and Wisconsin?
  2. On the Internet, no one knows you’re a dog.

Thus spoke The Programmer.

I Think We Are Kidding Ourselves

7 Sep 2015 /

More people have ascended bodily into heaven than shipped great software on time.Jim McCarthy


On the other hand, the number of people on LinkedIn claiming to have a demonstrated ability to lead software projects to successful completion, on time and on budget, as well as the number of companies seeking to hire such people, is infinite.

Thus spoke The Programmer.

Pain in the Neck

11 Jul 2015 /

Neck pain

I started going to physical therapy for neck pain . . .

“What kind of work do you do?” the therapist asks.

“Software development.”

“Do you sit a lot during the day?”


“At a desk?”


“Show me how you sit at the desk.”

“I turn sideways like this in the chair and lean on the armrest, then I kind of scrunch over and stare at a computer screen.”

“Oooh, that’s not good. You shouldn’t do that.”

“I know. But I get paid to do it and I don’t know how to do anything else.”

Programmers Don’t Play Polo

16 Aug 2014 /

On the product page for a book on software development principles, Amazon showed me this:

Customers also viewed ...

The product on the right — is that a bug in the cross-selling algorithm? I’ve worked in software development for about 30 years and have never met one person interested in the game of polo . . .

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 /

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:


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.


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 /

(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

Next Page »