jump to navigation

Another Old Line Conglomerate Gets It Wrong August 4, 2016

Posted by Peter Varhol in Software development, Technology and Culture.
Tags: ,
add a comment

I seem to be taking my curmudgeon role seriously. Today I read that Jeff Immelt, longtime CEO of industrial conglomerate GE, says that every new (young) person hired has to learn how to code.

So many things to say here. First, I have never been a proponent of the “everyone can code” school.  No, let me amend that; everyone can probably learn to code, but is that the best and most productive use of their time?  I would guess not.

Second, I’m sure that in saying that Immelt has put his money where his mouth is, and has gotten his own coding skills together. No?  Well, he’s the boss, so he should be setting the example.

This is just stupid, and I am willing to bet a dollar that GE won’t follow through on this idle boast. Not even the most Millennial-driven, Silicon Valley-based, we’re so full of ourselves startup tech company would demand that every employee know how to code.

And no company needs all of their employees to be spending time on a single shared skill that only a few will actually use. GE needs to focus on hiring the best people possible for hundreds of different types of professional jobs.  It may be an advantage for all of them to have some level of aptitude for understanding how software works, but not coding shouldn’t be a deal-breaker.

I have worked at larger companies where grandiose strategies have been announced and promoted, but rarely if ever followed through. This pronouncement is almost certainly for PR purposes only, and will quietly get shelved sooner rather than later.  And making such a statement does no credit whatsoever to Immelt, who should know better.


Software Testing is a State of Mind July 2, 2015

Posted by Peter Varhol in Software development.
Tags: , ,
1 comment so far

I was prompted to write this by yet another post on whether or not testers should learn to code. While it gave cogent arguments on both sides, it (prematurely, I believe) concluded that testing is a fundamental skill for testers, and discussed how testers could develop their coding skills.

The reality is much more nuanced. There are different types of testers. An automation engineer is likely to be coding, or scripting, on a daily basis. A functional tester using an automated testing tool (commonly Selenium, or perhaps a commercial one) will write or modify scripts generated by the tool.

And in general, we try to automate repeatable processes. Often this can be done with customizable workflows in an ALM product, but there might be some amount of scripting required.

But while coding knowledge can improve a tester’s skill set, it’s not required for all roles. And sometimes it can detract from other, more important skills. That got me to thinking about the unique skill sets of testers. There are unique mental and experiential skills that testers bring to their job. The best testers intuitively recognize the skills needed, and work hard to develop them.

  • Curiosity. Good testers do more than execute test cases. They look for inconsistencies or incongruities, question why, and don’t stop looking for improvements until the software is deployed.
  • Logic and Discipline. Testers do very detailed work, and approach that work in a step-by-step logical fashion. Their thought processes have to be clear and sharp, and they have to move methodically from one step to the next.
  • Imagination. Testers understand the user personas and put themselves in their role. The best can work through the application as both a new and experienced user, and find things no one ever considered.
  • Confidence. Testers often have to present unpopular points of view. If they can do so while believing in their own skills and conclusions, while also taking into account differing points of view, they can be successful voice of both the user and application quality.
  • Dealing with Ambiguity. It’s rarely clear what a requirement says, whether the test case really addresses it, whether an issue is really an issue, and what priority it is. Testers have to be ready to create a hypothesis, and provide evidence to support or reject that hypothesis.

These tend to be different skill sets than those possessed by coders. In particular, many coders tend to focus very narrowly on their particular assignments, because of the level of detail required to understand and successfully implement their part of the application. Coders also dislike ambiguity; code either works or it doesn’t, it either satisfies a requirement or it doesn’t. Computers aren’t ambiguous, so coders can’t write code that doesn’t clearly produce a specific end result.

Coders may argue that they produce a tangible result, source code that makes an application concept a reality. Whereas the work product of testers is usually a bit more amorphous. Ideally, a tester would like to say that software meets requirements and is of high quality, in which case few defects will be found. If testers write many defects, it’s interpreted as negative news rather than a desired result.

But organizations can’t look at testers as second class participants because of that. Testers have a unique skill set that remains essential in getting good and useful software into the hands of users. I don’t think that skill set has been very well documented to date, however. And it may not be appreciated because of that.