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!

Standard
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.

Standard
Perspective

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.

Standard
Perspective

‘Code is read more often than it is written’

My Blog has moved! You can find my latest content at daniel.scheufler.io. Please continue reading here.

At first glance, this would seem an obvious statement. And it is in a way. When Python language creator Guido Van Rossum created Python, he did so with this thought in mind. As a result, the culture of Python is partly molded around “readability counts”.

The more I thought that statement, the more I realized the marvel it held. ‘Code is read more often than it is written’. If asked to choose between reading and writing, I would have said the same. And yet I realized now, that much of the code I have read, and some of the code I have written does not show this. I wondered, why did my behavior, and that of my peers, not match what I knew to be true? If we believed that code was read more often, they why is so much of our code so hard to read?

At the core, our behavior remains unchanged because this quote is only an observation. There is not imperative contained in it. Without the means of an imperative, the observation cannot turn into an action. Instead the reader would need to derive ‘Code ought to be easily read’ from ‘Code is read more often than it is written’. I trust most would be equal to the task, given a basic desire to optimize.

When I first discovered this, I did not pay it nearly enough attention. I went blithely on my way. Some time later, during the quiet of a vacation, the thought came storming back. I was left dumbfounded. How could I have not seen it earlier? I realize now, it was because I had not given my self enough time to think. With the lighter load during vacation, I was able to think, and so naturally the thought came.

This moment of serendipity also encouraged other considerations. Specifically, what other imperatives had I missed with casual observations? I quickly realized this is dark territory. It would be difficult to turn every observation into a possible imperative. Worse still, these observations might be biases, leading to bad imperatives. Or they might be too weak to lead to a meaningful imperative.

In all cases, the question remains, what have I missed? I believe, especially in software, that we are caught in a rush to develop, to implement, and to finish. As a result, we do not give ourselves time to ask, ‘Is this the best way?’ Business demands that we move with purpose, and that is a reasonable demand. But for the best results, we need time to consider if we go in a way that will deliver us to the goal we seek. I will continue to look for miss-able observations may turn out to change everything.

Addendum:

While drafting this article, two other examples of ‘observation leading to imperative’ appeared. The first was fictional, from Foundation and Earth by Isaac Asimov. In the book, the protagonist remarks with surprise at the neural interface to a computer. Instead of being an over-the-head affair, it was through the hands. His realization was that humans sense and interact with the world through their hands. I may revisit this in a later branch of this discussion on design.

The second example, sprouted from the first, specifically interaction and design. Recently the IoT movement has brought integration to our homes. In particular, the voice-interaction, such as Amazon’s Echo or Google Now. I observed that these devices extended a natural principle: ‘Humans use their voice to make their wishes known.’

Standard
Perspective, Software Development, Work Projects

Where’d my UX go?

Disclaimer: I am not the happy looking chap in the photo.

I was working on a personal project recently when a realization dawned on me. User Experience Design,also known as UX design, and software design collide more frequently. And not only in the User Interface layer.

Before I get too far, when I talk about UX, I am referring to the experience the user has while attempting to use the device or object, or code. I think this image does an excellent job of describing good UX concisely.

Link: http://i.imgur.com/9LqhOl3.jpg

It’s pretty easy to tell what UX is like with a Graphic User interface, or a GUI. After all, this is the part everyone touches. If a website is snappy and the layout makes sense, that is good UX. If it is clear how to do the operation you want, without needing to consult the magic talking paperclip, then it is a good UX. But it seems that once you go below the GUI layer, the lessons on good UX vanish.

I was working on a Fluent Testing API for python when I realized it. In version 1, I had all the functionality for this API bound up in a single class. Sure, it limited the import tree, and made it easy for me to develop. For version 2, I decided to pull the functions into separate classes. And while I was writing out some example cases, I realized that this simple code change resulted in an augmented User Experience!

You see, by pulling the various functions into different classes, I allowed the IDE to create better prompts. The better prompts now guide a user of my API through the proper pattern of using my API. Since there were fewer functions to choose from, it is now clearer how to proceed. The user no longer has to consult a lot of documentation. This is a simple example, but it did get me thinking.


In fact, one week prior, I added a Facade to one of my library at work. The Facade simplified interactions with my  Library. Now other software engineers could more readily use my library’s functionality. I am surprised that I didn’t think of it at the time, but APIs are a Software Engineer’s UI layer. As a result, they should be subject to a UX review!

I mentioned earlier that I have noticed that, on the whole, UX degrades as you leave the GUI layer. Two factors are responsible, in my opinion. First, the majority of UX review and work goes into the GUI layer. And this focus makes sense. The vast majority of software interaction is through such a layer. As an aside, finding a UX guy who can talk about UX and about API design can be difficult. I usually have a heck of a time getting time with them to review a GUI design with them!

The Second factor is a lack of discipline. I am not throwing stones here, the first version of my Testing API is example of such a lack! I collected all the functionality in a single class because it was easier for me!  I wanted to get the functionality together and to reduce the import tree. In hindsight this is a silly reason. And yet, it was enough to change my behavior.

So now that I’ve seen the problem, what can I do? Well, I noticed the improvements made in the UX for version 2 by writing up some examples. That is to say, I used it. This is a good start, bu submitting it to user testing would be a better step. After all, as the design I was intimately familiar with the inner workings and the proper usage of the tool. But a fresh user wouldn’t be. And if there is anything I have learned developing software: the user never does exactly what you expect them to.

Besides more user testing, some cross-functional education might help. This recent epiphany put me in mind of a tech talk that I hadn’t finished. You can find the youtube video here. I am hoping that revisiting the principles from the talk will continue to improve my designs!

Standard
Perspective, Work Projects

So tell me, Why do we pay you?

 

 

So imagine this: you are sitting at your desk at work. When a mid-level manager strolls up and asks you the following: “Why are we paying you to do what you do?” Could you answer him? Would he understand the value of keeping you if you did?

Recently, I had a chance at work to answer this exact question. Thankfully, the situation was much more relaxed. You see a project that I am the technical lead of was awarded a Project Manager. To me this means that the business thinks that what I am doing is valuable. Valuable enough to pay someone to make sure that it is well staffed, organized and properly directed. I am pleased with the direction we are going.

But as one might expect, the Project Manager was not a software engineer. So naturally explaining the value of the project in software terms wouldn’t help. The make matters more complicated, the project is not customer facing. It is in fact a business solution, helping to tie many other services together.

Since this project had been without a Project Manager for a while, we had never completely translated the value of the project into business terms. As a result our first meeting with the PM experienced a little bit of a disconnect. We spoke about the value the software provided to other software applications. But our PM had some trouble translating that into meaningful terms for herself.

So following the meeting, I took it upon myself to attempt a business translation. I took what I knew about the project and its value and translated that roughly into business terms. I certainly did not do a perfect job. But I believe that some benefit may come from discussing what I have learned over the years and was able to apply to this project.

As I see it, Business Value comes down to just one thing: More Money. But there are two ways to achieve this end. Either you make them money, or your save them money. If you can translate your work into one of these two parts you can usually make a business case for it.

Our project was created to simplify the process of connecting many apps. The project would make it easier to maintain, and easier to extend the connections between application. It would also support new feature implementation. Moreover, since the new system is simpler, it reduces the likelihood of incorrect actions by our system. So how does one translate this into saving or earning more money?

If the project make it easier to maintain a system, then it reduces the man-hours spent on maintenance, right? If you save man-hours, then you are saving money right? If you want to go the extra mile, provide an estimate of how many man-hours it saves. Then multiply those hours by the average software engineer hourly rate. This provides a number of dollars that your project can save the business!

Since software projects often provide a benefit for many years; try to provide information about saving during a single year. So if I save 8 man-hours a month, I save the company 96 man-hours or 3600$ per year (assuming a salary of 75K$).

To take the example a step further, I can also factor in the cost of my work on the project. Let us say that it will take me 42 man-hours ( or roughly 1 week of work) to complete this feature. Then it will cost the company 1575$ to produce. The result is a net savings of 2025$!

Going back to my project, since it makes it easier to extend, the cost to implement it will be rather low. If you can quantify how much time it will take to implement your solution, you can provide a more accurate estimate to the business.

The project is designed to make it easier to add new features to our system. This means that it reduces development cost. Additionally, it means that the new feature can make it to the market faster. Do not under-estimate this! Faster Time-to-Market can provide your company a competitive edge.  The edge comes from either by being the first to provide a particular functionality, or by begin able to under-bid competitors. While it can be difficult to provide exact value numbers on this, you can highlight the man-hours saved in development. I find it easiest to understand by providing a comparison to the current process.

To provide a good estimate, I recommend using a current project. Comment on the time it took to implement the part of the feature related to the new project. Then compare it to the time it might have taken using the new project. This provides a tangible example of the value your project creates.

Finally, my project simplifies the logic of linking multiple services. This simplification reduces the risk of errors. To put a value on this, you need the time saved. Start with the current time spend debugging. Then estimate the how much your project would save, based the project’s implementation.  My project simplifies by pushing the logic into a more appropriate context. It also allows the using services to dictate the communications they wish to react to. As a result nearly all the current bugs could be eliminated. Not 100% of course, but a sizable chunk, perhaps 70-85%. Using this estimate, you can translate the man-hours saved into dollar value as before.

Translating from software value into Business value isn’t always easy. But it is doable. Further, it is quite approachable if you have the right mindset. How am I saving the company money, or how am I earning them more money? Once you have these answers, you can begin the translation into business terms.

To be sure, the estimates you provide when you first start will be a bit optimistic. But with time, practice and experience, they can become more realistic. I am certain that the estimates I provided to my PM were lacking in some respects. But something is better than nothing! And I got to learn a valuable lesson in translation!

If you have a project to translate, I’d be happy to discuss! If you have any pointers, I would appreciate your suggestions! Just send me a message! Good luck and Happy hunting!

Standard
Software Development, tools

Dev Tool: Atom – Revisited

Atom is Github’s hackable text editor. I was introduced to it by a friend in college. Since then I have used it for various tinkering projects in Python, and an Arduino project with a couple of friends. Atom is awesome!

Atom doesn’t ship with support for everything, which is alright. But what makes Atom great, is that it is extensible! It has a rich marketplace of published extensions offering support from Python to C, and Json to Yaml. I discussed some of the packages that I used to support both python and Arduino in my previous post.

Lately, I have been using Atom as my go-to REPL environment. Now, there are other tools like repl.it, which are great for rapid feedback tinkering. However, I always feel … iffy about online solutions. They can be great, but if the power is out, or the internet is down, or worse slow… well there go the advantages.

But last week, I started to notice that my instance of Atom was starting a bit slow. Mind you it was just a few seconds, but it was noticeable. So I started hunting. After a while I found that Atom ships with a plug in called Timecop. Timecop tracks performance times of the modules that you have installed and active. It tracks the load time, the init time as well as other associated metrics.

As I started snooping I found that several of my modules were really slowing me down. For example, a bit more than a half second was lost to Omnisharp, which I had loaded to support C# tinkering. Additionally the C Language Linter Library also ate considerable time.

C and C# are not the fastest REPL languages for me. As a result, I decided to pare down the modules that I had supporting them. Now don’t get me wrong, I love C# for business development! I just feel that it can be cumbersome for REPL workflows. So, I uninstalled some of my modules, like Omnisharp. But for C, I just deactivated them. This is because C is often used for Robotics and Arduino Associated applications.  Since the modules were still installed, I could turn them back on. Thus the features can be used without incurring the start-up cost every time I launched Atom.

All in all, this was an interesting exercise, and I thought that others might benefit from hearing about it. I am rather pleased with the results. And after gaining this experience, I am think that my next challenge will be to write a plug-in or module myself! I recently found this tutorial that I think will help.

As always thanks for your time! If you found this post interesting, I would encourage you to check out my personal blog. I have several posts on Development Tools that I think you might like!

This was originally posted on LinkedIn with the Title Dev Tool: Atom. Since that was the original post’s title, I have changed it. Further, this post originally refered to the plugin as Timeit. I discovered later that was incorrect. I have applied this correction here.

Standard