Empathy, Engineering, and People

A discussion of empathy in engineering:

Erin Cech at Rice University agrees that empathy is essential and names our current culture in engineering a ‘culture of disengagement,’ one in which engineers focus almost exclusively on technical details with little or no attention to empathy and moral issues. Cech’s recently published results show that engineering students’ level of empathy decreased over the four years of their engineering education. Yikes. Not only are we attracting students with lower empathy to begin with but they become less empathizing over the years of their engineering education.

Why is empathy essential in engineering? Engineers design and build products, yes, but these products are for people! To design effective products and processes engineers must understand the people who will use them.

[emphasis mine.]

For all of the focus on technology, on building things faster, more efficiently, it’s all for naught if it doesn’t serve the user’s needs. If we’re not solving someone’s problem, then what’s the point?

Master the basics first

Very good advice:

Until you can reliably deliver what you thought you could deliver, focus on how you define and build software. You don’t need Lean or Kanban or to improve your stand-up meeting. You need to learn how to define, build, and deliver software.

Don’t be distracted by nuance if you can’t get the basic gist correct. Deliver what you say you will deliver. And only work on that until you can do it. Be functional first. And then work on refinements.

Regulating development

An interesting post on the Ken Schwaber blog:

Our  shortcomings were surprising to me. When I rolled out Scrum, I thought that the excellent developers that had been stifled by waterfall processes would emerge, and we would again do great work and build great software. Much to my surprise, many never had those skills or had lost any skills they had. The pressure of “get it all out now, cut quality to do so” had reduced most developers to unskilled, unprofessional, angry drones. The larger the organization, the worse the situation as “mediocrity scaled.” Organizations whose software is only five years old are already crippled by technical debt.

He posits that governance of software developers is imminent – whether the industry elects to self impose these guidelines or the government demands it – and that formal regulation of skills and capabilities is needed.

It reminds me of my real estate days – an industry with a very low barrier to entry, and an extraordinary range of practitioner proficiency.  (Sound like software development to you?  Yeah, to me, too.)  There is a plethora of “certifications” that are intended to provide proof of an agent’s skill.  A Certified Residential Specialist?  How about a Graduate of the REALTOR Institute?  When working with an agent with a set of fancy letters after their name, did the transaction proceed more smoothly?

Not generally, no.  In my experience.  They’re generally pay to play: read the handout, sit in a chair and exist for the required number of hours, pass a simple test, pay the man for the honor of putting the letters after your name for a year.  Clearly, this is not the model to adopt.

This, however, is certainly a problem:

If I were on a team, I wish that I knew the level of the developer that I was bringing on board, instead relying on personal references and “the usual suspects” to avoid getting swamped by unfounded braggarts.

I don’t personally believe a governance board can replace screening candidates for my personal standards for proficiency.  Might it give me some warm fuzzies that the candidate has at least tried to gain a skill?  Possibly.  But in a world where even a college degree is seen as optional, an archaic proof of capacity, what can a governance board provide?

It’s an interesting thought.  Can you regulate development processes across an entire industry?  Can anyone really certify skill, if proficiency is a relative determination?  Things to ponder.

how to ensure you’re always worse than you could be

I’m a little OCD. 

I’m a little exacting, and precise.

I blame it on my background.

I’ve got an engineering degree where I was taught to define and measure systems.  To improve performance, reduce risk, to evaluate alternatives and measure results.  I spent a quarter century in a ballet studio, perfecting the nuances of both small and large movements, where every tiny detail counts, from the specific lift of a pinky to balancing your entire body weight perfectly centered on a single toe.

It made me an awesome software tester.  Quality assurance and me are like peas and carrots.  It’s part of who I am now.  I can’t visit your site without automatically thinking about ways to break it.  I can’t look at your form without wondering how much testing you’ve done to improve conversions. 

And I get a little frustrated when things don’t work.  Especially stuff that I consider pretty basic. 

I get even more frustrated when I see you trying to fix those things without any regard to testing, or to quality.  Just code the fix, cram it in, and move on.  And when I run into the exact same problem after you’ve told me it’s been fixed?  Lather, rinse, repeat, I guess.

Testing has always been the red-headed step child.  No one likes it, no one wants to do it.  No one wants to implement testing systems at the same time they start development.  So by the time anyone starts testing and running any kind of quality control, it’s already too late.  Your testers will find problems you should have fixed years ago.  And while your dev staff wants to move on to the next fun new feature, those pesky testers keep shouting about the same old stuff that still doesn’t work.

If your development staff is running your testing?  If they’re checking the same code they just wrote?  You’re screwed.  Not only does your developer hate testing, but they’re not objective anyway.

I used to test the software that runs traffic lights.  I did that for 5 years, banging away on the same thing, running through the same battery of tests over and over and over again.  And then I’d do it all over again on multiple operating systems.  For each iteration of the software.  Because if the developer missed something, and I didn’t catch it, there was potential for huge danger.  Putting an entire city of street lights into flashing red, simultaneously.  Not making the light at a railroad crossing change fast enough when there’s an oncoming train.  Some major safety issues.

Now, maybe it isn’t life or death if your little widget doesn’t go blinky-blinky at the right time when I enter a properly formatted phone number.  But if you haven’t implemented independent, iterative, consistent testing for whatever it is you’re doing?

Then you’re creating a sub-par product.  Simple as that.