Software Development, Work Projects

Going where no QA has gone before!

As a developer having QA you can rely on is great! They are welcome friends helping us cultivate our precious software. But there are dark places which even a QA cannot shine a light. When your software has no interface, what can a QA do, but wish you luck? But what if there was a way for QAs to interact with otherwise UI-less software? Enter Cucumber, a tool that allows QA to shine a light in dark places.

I rediscovered Cucumber, while researching test automation frameworks. Cucumber is a framework for Behavioral Driven Development. After experimenting for a time, I realized Cucumber opens a whole realm of possibilities. Cucumber encourages the expression of program actions in the human tongue. With a proper translation mechanism, Cucumber could act as a mediator between QA and the UI-less software. 

Cucumber translates the human tongue into functions through the Gherkin language. For example, a tester would define a test case like this: 

Scenario: Messages are saved until the consumer arrives
Given the queues are empty
And I publish a message to the queue with ‘SomeDetails’
When Alice subscribes to the queue
Then Alice should receive a message with ‘SomeDetails’

It is fairly easy to understand the behavior that is being described in this scenario. Cucumber ties the keywords Given, When, and Then to functions which execute the described action using a Regex Match string. This can include free-hand parameters such as ‘SomeDetails’. 

Properly designed, the Givens and Whens can be setup to be repeatable and re-compose-able. Doing so allows the QA to describe more complex scenarios with different combinations of the same simple behaviors. As a result, once the initial steps are available, a QA could test to their hearts content with little developer support.

Cucumber improves the documentation of a product. Test document expected behaviors in a common tongue. This makes them available to all parts of the company.

But great care must be taken to ensure that the compose-able parts function precisely as described and without side-effects. Imperfections in the design or the aforementioned side-effects will destroy test-validity and erode trust in the test cases written using Cucumber.

Cucumber was designed to improve TDD, enabling members of a team to describe the function of a program in a human tongue. This same feature creates a tool for empowering QA. Given careful planning and design, you can compose a terse but flexible set of instructions. These allow a QA to test projects they could never touch before! By blending the skills of a developer and a QA, we can reap the best of all our talents. All it takes is an investment to allow our friend in QA to come with us!

Perspective, Software Development

For the love of the User

Software is for the user. It is not for the Software Engineers who develop it. In the end, software will succeed or fail to meet user needs. The user is the arbiter of software’s fate. Oddly though, many software developers tend to resent their users. The users are prone to strange behaviors. Sometimes they can even come across as whinny children to jaded developers. But we must do away with this flawed way of thinking. We must act as humble stewards, gentle of heart, and eager to please.

Users are the life blood of a software product. Without them, the product will fail. As a result their needs are paramount, and must be address to the best of our abilities. If this is the case, then why are developers so often frustrated by their users? Remember we are fluent in the machine tongue. Generally speaking, users aren’t. Sure they can use the machines, to a limited degree. But they don’t understand them like we do.

Imagine you are in a foreign country. The only way to get your work done is to cajole a lumbering beast into action for you. Without understanding the beast’s language, even simple tasks could be infuriating. Users who are less familiar with software might feel the same. Only remember that we specialize software to particular tasks. As a result users need to learn, remember and use a variety of these ‘beasts’ to get their work done. Also remember, they are being evaluated by their ability to get work done, using your software.

And so scared, frustrated, and feeling impotent, they turn to us. They wonder why their actions did not work. They ask for strange features or work-flows. All these feeling arise because they don’t understand their tools. Sure we could ‘educate them’. But if the way to use a tool is less than obvious, or they only use it seldom, then you can expect them to forget. Not to mention, you have to convince them to take the time to get trained, rather than working. Even we don’t feel comfortable trading training time for working time. So why should we ask that of them?

Two paths remain to us. We can tell the user’s they are wrong and constantly bicker with them, trying to explain the proper way. Or we can choose to listen. The way we thought was obvious is not. They need more help, because the grammar of machines is difficult. I would call this path ‘Stewardship’. We have to think of the code as belonging to the users, not to us. In so doing, it becomes clear what choices we need to make. If the code is for the user, then their needs overrule ours. If they aren’t fluent, we must may the software more approachable.

We are like gardeners. The land we tend is not our own, but still we make it bloom with brilliant flowers. We cherish the blossoms, and suffer when they are trodden upon. But the garden is not for us. Imagine if the gardener chased off the owner with a spade when he ask for a new row of lilies. The gardener would be marched off and a new one brought in to replace him. This is not an exact analogy, since users pick their software. They might just avoid a certain gardener altogether.

If instead, we are gentle and approachable, we could better tend our gardens. If no one ever walks our garden paths, then we put to waste all the love and beauty to garden contains. Software without users, despite its brilliant design, and delicious complexity, is dead. If we want vibrant, living software we must serve our users. We cannot lord our understanding over them, but must instead steward the code for them. With gentle hearts, we can learn their needs, and make the garden they need. In the process we may discover an even greater beauty.


ROI of Training

What kind of investments do you make? Do you favor immediate returns on investment? Or do you favor guaranteed returns? How long are you willing to wait? Time spent in training or practice is equal to making an investment. Different methods or focuses produce different results.

Much of the training available in the software industry focuses on new frameworks. With a myriad to choose from, there is no shortage. There are many introductory courses. All encourage picking up the tool and applying it to basic problems. Yet these frameworks are subject to change. Two years down the line the framework will change. Sometimes in two years it can become obsolete. In other cases, it becomes an industry standard.

All in all, these skills degrade. Some of the degradation comes from market changes. Lack of practice also contributes to the decay. How often do you truly use that obscure array access format in language so-and-so? Rarely, for most of us. Yet there is a class of training and investments that are less likely to degrade: People skills.

People skills are usually presented in management or leadership courses. They are an investment class of their own. The opportunities to practice people skills are vastly more numerous. As a result they do not suffer as much ‘lack-of-practice’ degradation. Furthermore, people skills remain in demand for many higher level positions. Want to be a consultant? You need People skills. Want to start your own company? You’re gonna need people skills. But these skills are difficult to acquire. In fact, these skills are in high demand precisely because they are difficult to acquire.

People skills are also applicable across industries, if you ever wanted to move. The skills of a software developer carry over any industry we develop for. Much the same way, the core skills of a manager translate well across industries. As career capital, they pay large dividends.

The best investment for anyone strong depends on what they want from life? I enjoy the challenge and rewards of programming. But I am interested in the role of management, and in its unique challenges. With an eye to the future, people skills appear to be the best investment. The skills suffer less degradation with time, and have remained in demand over the long haul. What do you value in your investments? Do you want to expert in technologies? Or do you want to diversify? Hopefully this perspective provides another lens for reflections.

Perspective, Software Development

What are you looking for in your interview?

What’s the point of an interview? Before you jump to an answer, do you give your candidate’s coding tests? Some white-board challenges? Have you ever wondered why? Do you think it’s the best way? Recently I’ve encountered opinions that counter the traditional wisdom filtering candidates. shared data that shows LinkedIn Endorsements don’t correlate to a candidate’s actual skill.

Recently, respected programmers have taken to Twitter to confess their programming sins. This prompted a discussion on the technical interview questions by The Outline. There is even a small industry to prepare candidates for Whiteboard Challenges. In the end, the hubbub about Whiteboard challenges comes from the fact we are using them wrong.

We interview this way because Employers need to feel comfortable about a candidate. For Software, this means verifying the skills of the candidate. And to a lesser extend verifying their ability to communicate. This sums up the entire purpose of an interview.

But what does my answer to a whiteboard challenge actually mean? Is there such a thing as a ‘correct’ response? At a deeper level, does my answer truly reflect my skills as a developer? I say it does not. It does not reflect your skills, unless you are referring to the ability to communicate/reason by drawing boxes and lines.

Don’t get me wrong though. The ability to present your designs on a whiteboard is a useful skill. But it is not the skill that an employer wants to check. Unfortunately, there isn’t a good way to measure some of the skills without seeing actual work. ‘Take-home tests’ in the interviewee’s preferred language are much more useful. Whiteboard challenges do not demonstrate the same skills.

That is not to say you should toss out Whiteboard challenges . What we need is to change our thinking. Whiteboard challenges may not show an interviewee’s ‘coding’ skills. But they do show the manner in which an interviewee thinks. If you ask someone to write out an algorithm on a whiteboard, you will see how they think about the algorithm. You will see how they remember it. If you ask them to create a new algorithm, something unique, you can learn how they explore a new problem. You’ll see what details they pay attention to. Moreover, you can introduce new requirements after they get started. This reveals how they will adapt.

All these insights are useful to know. But they are far less tangible/measurable. As with most hard to measure qualities, we tend to fail at measuring them. As a result, the tools created to measure them begin to be mis-used or mis-applied to find other tidbits. It ends up like using a fork to eat soup. It’s not very effective and wears you and your server out trying to get anything done.

So, if an interview is about revealing the skills of the interviewee, then we need technical interview questions. But using Whiteboard challenges still provides some benefits. But we cannot use whiteboard challenges as a litmus for programming skills. Instead, we should use them to pose unusual challenges which expose the way the interviewee thinks. This new form can also reveal how interviewees adapt to adversity. Those insights combined with more traditional evaluations will help businesses to find stronger, more suitable candidates. These candidates will be stronger not merely from a technical perspective but also from a cultural one. All it takes is using the tool for its proper purpose.


Software Engineers are actually ‘Creatives’

Have you seen the Project audio for Github? Or the plethora of esoteric languages like Piet or ><> (pronounced: fish)? Recently I had a ‘coding challenge’ for fun at work. The challenge was to print a poem in a language we didn’t already know. In that time I’ve picked up four such languages, which got me thinking. We, developers, enjoy some of this artsy kind of stuff. Sure it’s not your typical artwork, except for Piet. But it is very creative at heart. Then the light-bulb lit up, Software Developers are members of the ‘Creatives’ community.

To be clearer, ‘Creatives’ is the group of designers, and artists who contribute to projects in more media-centric ways. For example, the icons, the color scheme, or the marketing campaigns and slogans all fit the bill. Software Engineers are usually inclined to disdain the ‘Creatives’. This is because it is harder to measure what creatives actually do. But I suspect there are some lessons we can learn, if we would open our eyes.

Generally, one manages ‘Creatives’ in a particular way. The method enables the creative freedom. It also establishes the safe environment needed to ‘try something new’. This allows them to bring their brilliance to any given project. This environment makes sense for the product they deliver. If a creative team does not feel safe, very few ideas appear, leading to lack of success. Of course, such an environment is difficult to setup and very easy to tear down. One cruel word, or breach of trust and the system comes toppling down.

In contrast, many software development teams are more hierarchical in their style. Additionally, there tend to be more men than women. As a result, software teams tend to favor codified leadership. We like increased authority rather than community, at least in traditional corporations. Most design ‘discussions’ are arguments in fancy dress. And sometimes this can work well, since engineers usually like to debate. But we should consider adopting some strategies from the ‘creatives’ side.

A safe environment with respectful discussion rather than debate could be desirable. This environment would allow us to foster new and brilliant solutions. In order for this to work, software developers would have to realize they are ‘creatives’ too. We would have to change our ‘comfortable’ behavior to allow for a better team environment. This, of course, comes down to culture, but also to maturity. We must be mature enough to admit we might have missed something. And we must be mature enough to want the best ideas, rather than our own.

At a manager’s level, if Software engineers are creative, then we ought to manage them differently. Dictating the chapter and verse of a solution you want is unproductive. It limits the benefit you can gain from your brilliant engineers. Instead, we need to challenge them. Provide them a problem and your rough idea of a solution and then encourage improvement upon it. Don’t dictate your needs as you would to your digital assistant. Rather begin a discussion about the best way forward. Before committing to deadlines, allow for ideas to circulate and then commit. Who knows, maybe we can learn something from those crazy ‘creatives’ in the east wing after all?


Software Developers are Translators

What is a Software Developer? I know they ‘develop software’. But that is like saying water is wet. What is the fundamental action we train software Developers for? Could you use it to distinguish to excellent from the mediocre? I’d say you can. The fundamental task for Software developers is translation. Software Developers are in essence, translators.

Software Developers are individuals who can speak both to man and to machine. At a low level, they literally translate human sentences and ideas into instructions for computers. Ever used a poor translator app? Then you know proper translation takes some finesse. You have to understand the culture of the language you are translating to. You need to understand the idioms and the proper grammatical structure. Otherwise your translation won’t turn out well. It might sound like terrible high-school writing. Worse, it might be a hollow mechanical echo of the original work.

The difference between a ‘good’ developer and a mediocre one hinges on the mastery of the language. The good developer knows the right idiom to convey the fine details of a phrase, while the mediocre developer might be able to eventually explain the instruction. The good developer can instruct with elegance and in some cases even a flourish. This even extends to translating behaviors. In technical language this is the UX. A good developer accounts for the expectations and the wants of those using it. He elegantly handles the use case. The trouble comes when trying to quantify these differences. They are differences in quality rather than quantity. But that is for a different discussion.

A good developer also recognizes the short-comings of the medium. Some things can translate when in their original form, others need to be recast. The target language/culture may not be able to sustain the desired content. Vocal inflection is useful for in-person discussion. They do not translate well into text message. Instead they need to be recast to maintain their emphasis. Put in plain language, computers can only do so much. A good developer recognizes the limitations of the system. He then communicates these limits to the humans he is translating for.

In a proper environment, the software developer would act as a representative of the machine to man. The good developer would help him to understand the needs and abilities of the machine. At the same time, the developer would act as a representative of man to machine. He would ensure that behaviors would meet expectations of man. These two tasks would form a cycle. The developer brings the needs of man to the machine. Then he returns with the limitations and requirements of the machine. Over several cycles, and accommodations, we find a successful system. In spirit this cycle is like Agile software development, though without the extra trappings.

Now if a Software developer is a type of Translator, should we change how we measure them? We can or ought to borrow from the way the Translation business operates. Or adopt their performance measurements? A good software developer acts as a fluent translator between the worlds of man and of machine. Through clever use of language, they translate the desires and needs of men to the machines. And then they bring back the requirements and limitations of the machine. In a proper cycle, both can prosper from this feedback. The good software developer is like a good translator. He is aware of the idioms of his target language as well as the culture. Thus he can make an effective, compelling translation of the original.


A chance encounter: Leadership on a Competition Show

My wife has recently been hooked on a Competition Series on Netflix. It’s called ‘Skin Wars’, and it is a competition TV show for body painters. It follows the standard model of such shows. Think Americas Next Top Model, or The Next Food Network Star. Normally I wouldn’t watch such a show, but even I have to admit the final products and artwork were impressive. So on occasion, I would watch an episode with my wife, while doing chores or something.

On such an occasion, we were viewing Season 2, Episode 5 ‘Emotional Rollercoaster’. The episode’s main challenge was a Horror-themed pieces made by two teams of four. As the episode unfolded, a curious dichotomy of leadership blossomed. I encourage anyone with access to review the episode. The examples are exquisite! The dichotomy centered on trust. One team grew to trust their team captain. The other started with distrust, and it only festered. Ultimately, that distrust between the team members lost them the challenge. I will focus mostly on the successful captain, hereafter Captain A.

At the beginning of the challenge, he assembles his team for a brainstorming session. Under normal circumstances, creatives can be rather shy about their ideas. They tend to be caution when offering truly unique or ambitious ideas to a group. I was pleasantly surprised to see Captain A handle the situation with such grace!

Captain A asked the group for their input. They bounced some ideas around. Then one of them offered and idea, but immediately backed down suggesting it was foolish. Captain A instead endorsed the idea, praising the team member. The effect was as impressive as it was immediate. You could see the praise taking hold in the proposer, as he smiled and the team began to build on his idea.

In contrast, Captain B chose to dictate her vision to her team, and then ask for input. When team members proposed an idea, she did not exactly reject them… but she didn’t praise or accept them either. The team saw this, and almost immediately began working with a fend-for-yourself mentality. At the end of the brainstorming session Team A had a single cohesive idea. Team B had to cobble together four distinct ideas into a reasonable story.

During the challenge, Team A optimized either activity. The most skilled member handled their specialized tasks, while still managing their one works. The Captain would occasionally walk around asking if anyone needed help. He also directed the team in certain instances, to ensure the joint effort would work. As a result, the captain’s entry suffered from the reduced attention. Several team members remarked about this to each other. I could see the trouble brewing for the end of the challenge. It is standard fare in these types of challenges, to ask each team member who did best and who should go home.

I remarked on the brewing trouble to my wife. The captain had an interesting choice ahead of him. He could ‘save himself’ and throw someone else under the bus, or he could prove his mettle and throw himself under. This prompted my wife to bring up team B. Their captain had a better entry than one or two or her team member. My wife asked ‘what if the captain’s work was actually better?’ My response was ‘unless the captain’s work was markedly superior, not merely better, the captain should not nominate themselves as the best. And even if their work was better, they should never mention a team member as least good. They would immediately lose their team by doing so.’ I didn’t realize the semi-prophetic nature of this discussion until we resumed the episode and watched the judging.

As expected, the judges began asking the participants who should stay and who should go. To my great surprise, Captain A called out the artist who had proposed the team’s theme as the best. When the moment of truth came, he selected himself to go home because his work was not his best. The team, looked mildly surprised. But they all seemed to support their captain, providing mitigating evidence for his lesser quality. It was rather touching actually.

By contrast, team B seemed to turn in on itself. Captain B nominated herself as best, and threw a team member how hadn’t produced their best work under the bus. The rest of the team nominated one of their own as best and generally had little positive to say about their ‘glorious leader’. In the end, one of team B’s low performers went home, and all the remaining competitors became wary of Captain B.

This episode had demonstrated in real life a concept I had mostly seen in books. A leader who can build the trust of those they lead will succeed. But trust is a fragile thing, and must be guarded. In some cases, this required the leader to eat some humble pie. In others they must be willing to let someone else take the spot-light. I’ve heard this called ‘Servant-Leadership’, or ‘Realizing that it’s not about you’. Both fit in this case. And I was thankful for the brilliant demonstration.

One final note, in the next episode, the teams were dissolved, of course. Everyone returned to their individual competition. But I noticed a curious phenomenon with the members of team A. They still showed signs of a camaraderie built during the previous challenge. Among the joking and jostling, I believe there were some helpful hints and aids given between ex-team members. I was surprised that the short stint on a good team had this kind of lasting impact in a show about competing with your neighbor.