Tuesday, January 27, 2015

5 Reasons to Manage Your Solo Project’s ALM Process

ALM soloSo I’ve been developing software on the Microsoft stack for just over 10 years, and training and consulting on managing software development with VS-ALM (a.k.a. TFS, a.k.a. Team System) for just over 4 of those years. But in all time training and consulting, I was working with teams – from small 5 person start ups, to enterprises with hundreds of users, all using Team Foundation Server (a.k.a. on-premises TFS) to develop their methodology and align their tooling with their products.

Never individuals, though.

Over the years, though,  I’ve had the opportunity to fly solo on several software projects, some short lived, some longer, as have other ALM consultants that I know. One thing we all seem to have in common is that, while as ALM experts, we have all of the skills and knowhow to apply our own trade to the software we develop, we seldom – if ever – do so.

The Cobbler’s Children Go Barefoot…

… as the saying goes. It seems that this proverb applies to our profession as much as it does to others. You’ve seen the doctor who smokes, the out-of-shape coach, the technician or plumber whose own wiring or plumbing is faulty, respectively. Perhaps it’s the same. Perhaps its just that proper ALM is more visibly useful when multiple hands are involved and they must all communicate and interact properly with each other, than when one person holds all roles.

Solo projects seem to need no management, I believe they only seem to.

Here’s why:

1. If You Don’t Use Source Code Version Control, You’re an Idiot!

The_Stupid__It_Burns_by_PlognarkI apologize for the vehemence. Let me rephrase this. If you don’t use some kind of source code version control, you’re an inexcusably dense idiot who deserves what he or she gets when you lose your source code!!!

I guess I couldn’t rephrase it without the vehemence. Lesson learned.

Beyond the fact that having some kind of backup, preferably online, means that even if you lose your laptop, or accidentally delete your source files, you still have a copy of your code, version control means that if you make a mistake, you can still rollback to that point in time and fix whatever you did wrong. Having a historical log of the changes you made to the software can also serve as release notes of sort, and a rudimentary list of the features and bug fixes you have, and even help establish some kind of time line.

Really though, version control is about security for the code – protection against loss and against mistakes. you should use it as frequently as possible.

Note that you do not need to shell out huge amounts of money to be able to use version control. In fact, as in life, so with version management, the best things are free!

I prefer using Git. You can use it locally with any operating system (Windows, Linux, Mac OS), and there are multiple online tools that work and synchronize with Git, all free: GitHub, CodePlex, and (my personal favorite) Visual Studio Online. There are, of course, other version control systems, both distributed and centralized (Mercurial is another DVCS, Subversion is a great free centralized one).

Heck, even use DropBox or some other online-syncing file-storage, just beware that it won’t protect you from deleting your code, nor will it let you rollback – but at least you’

2. Defining (just enough) Work Upfront = Less Code Writing and Rewriting

backlogMuch like TDD tends to limit the amount of production-code you write, so does defining your work. In fact what is TDD, if not the definition of a small amount of work that needs to be done to the system, along with a definition of how to know when you’re done? The same holds true for defining a development task, a user story (a.k.a. a product backlog item, or PBI) or a feature; each is an elaboration of the higher level: Feature to user story, to task, to test. When you know what needs to be done, and you know when you’re done, you know exactly what the remaining work is. That saves time.

And let’s be clear. Just enough is key here. Too little, and you’ll rewrite anything that you haven’t properly thought out and planned. Too much, of course, and changes to the reality surrounding the project and your perception of reality will bring rewrite to your plans.

3. Project Planning Makes it Possible to Plan Releases

Unless you are truly working on a hobby for yourself, you still need to be able to answer at least these two questions:

  1. When will it be done?
  2. What will be done by a certain date?

Without estimating the work you have to do, more so if you don’t even know how much work you have, you simply will not be able to give more than a POOMA estimate.

Note that unless you live alone, you might still need to answer these questions, if only so your partner, roommate or parent will know when you will finally clear the garage (or dinner table) from your junk.

4. Automation Reduces Human Error as well as Manual Labor

vitruvian-hiEven if you are a solo programmer, two things remain invariably true for you:

          1. You’re only human.
          2. You’re only one human.

Being only human means that as talented as you may be, you are still prone to repetition based errors. You’ll forget to update the version number, or forget to set the build configuration to Release, or forget to run the tests, or any number of things. When I train new developers, especially in those early days when they feel that the fact that they’re constantly making errors, and more experienced developers must be demigods or some such, in an attempt to reassure them (and lighten the atmosphere), I tell them this:

  • There are only two kinds of developers: experienced, and inexperienced developers.
  • Inexperienced developers make only two kinds of mistakes: Mistakes born of inexperience, and mistakes born of stupidity.
  • Experienced developers make mistakes only born of stupidity

Aside from the fact that this is inherently true (an experienced person, by definition, cannot make a mistake born of inexperience), it is important to note – experienced developers make mistakes!

Computers do not. Ever.

Another saying that I’m fond of repeating, the former statement being a key reason to do so, especially when consulting and or training clients on the use of ALM tools, is to never let a human do a machine’s work (and vice versa). Anything a machine can do, we shouldn’t.

Finally, there’s the fact that any time spent on doing what someone, or more importantly, something (i.e. your computer) could do, is time not spent on things only you can do (i.e. developing the product – which you’d probably prefer to do anyway). Ask yourself this – while you’re manually doing repetitive work – who is coding? Nobody.

This holds true for building, for testing, for releasing and deploying, and basically for anything that you can (and know how to) automate.

In all but the simplest and most straightforward scenarios (usually short-term, one-shot projects), you should find ways to delegate work to a machine.

5. Defining the Work Makes Change Management Easier

It’s all great when you’re hacking away at that pet-project of yours and you’re in the zone, but a week later, a month or even three later, once you start delivering a second or third release of your software, keeping track of what was done, when – not to mention writing release notes, becomes extremely difficult, if you don’t know what your changes are or were. In fact, if you use an ALM tool for tracking features, changes and defects, and associate them with automated builds, you can generate a release notes document automatically with every build, and not have to deal with it yourself.

The other kind of change, is change of management. Today this may be your solo project. Tomorrow, who knows? You may take on a partner, give someone else the code to maintain, or decide to open the source. If the only definition of the work is whatever lies inside that wonderful brain of yours, hand-off will be a bear. Trust me. I’ve had to waste two weeks once receiving a project, and I still don’t know everything about it. Finding out stuff on my own is not the best use of my time. Having a nice set of features, tasks and bugs (past and open both) shortens the time, and makes discovery pains all but gone.

Conclusion

In summary, I’d like to state my opinion that in most (again, all but the simplest and most straightforward one-shot) software projects, proper ALM is as useful and important when flying solo as when developing with a team. Lack of communication issues (though see point #5) are balanced by the increase of work of having to do it all by yourself.

Just do it right the first time. You’ll thank me for it.

Best Regards,
Assaf Stone
Occasional Solo Developer

Friday, January 23, 2015

5 Ways Project HoloLens May Change the World

Ok. So I have just right-clicked the word “HoloLens” and selected Add to Dictionary from the context menu. I believe that this word will be there for a while, and sooner or later, on everybody’s lips.

In case you have been out of touch with technology news in the past several days, HoloLens is Microsoft’s newest device, still in its earliest development phase, which has been unveiled for the first time (after many super-quiet years of secret development) at Microsoft’s Windows 10 Event in Redmond, VA.

Meet HoloLens

HoloLens is Microsoft’s leap in to the virtual reality – or rather Augmented Reality – arena. Wearing HoloLens will allow you to view the reality around you, with holographic images, videos and even sound overlaid on your surroundings, allowing you to interact with it with natural gestures and voice commands. Imagine being able to see a video on a virtual screen where your wall should be, or a floating instructor – either virtual or a real person on a Skype call – along with arrows and guidelines for, say, fixing a sink. Imagine your game world overlaid on your real world!

There are a lot of different ways to use HoloLens, or a similar device, and most people whose comments I’ve had the misfortune of reading, seem to see a cross between an even weirder-looking Google Glass, and Yet-Another-Gaming-Console-That-Will-Never-Replace-The-Controller-We-Already-Have.

I disagree. I think that the sheer number of possibilities such technology can offer is mind-staggering and goes far beyond gaming and taking pictures and videos of others on the street without the subjects knowing it.

The following list comprises what I believe may be the five most pronounced ways that HoloLens can change how we interact with the world around us.

1. Virtual Privacy

Not my office. Just a picture off the netMany people in various industries are victims of what seemed to bean-counters like a great idea. Cubicles, bullpens, hotel-desks. No matter how you call them, Work environments where people who are not collaborating on the exact same task are forced to endure noise and distractions from others are detrimental to productivity. At my current job I sit at my (small) desk, and am surrounded by people who are almost constantly on support calls that 90% of the time have nothing to do with me. There are also at least one man and one woman who seem to be chattering about non-work related issues, at least half of the day, everyday. The noise is annoying. Add to that the fact that there’s no privacy – my calls, my screen, etc. Personally, I hate having to think that someone may be looking over my shoulder while I’m browsing, reading, coding or answering emails (unless I asked them to). Finally, I miss the gigantic whiteboard that I had in my office, the last time I actually had an office. Just something that I could always look up to from my screen, so that I can verify or validate some design decision. So I work from home as often as I can (though I still miss my whiteboard. My wife just won’t let me put up one in the living room where I work…).

Only at home, while I do have my privacy,  I only have my (two) laptops – no 24” screen (its on my shopping list), much less two of them. And my really good keyboard and trackball mouse are at the office.

Enter HoloLens! Imagine coming in to work and putting on your HoloLens and sitting down at your… virtual office. That giant whiteboard? Hang it wherever you want. Might as well share a virtual strip of wall with anyone else in your office. It doesn’t matter. You see your whiteboard, I see mine. Or just hang it in the air. Look up to it any time you want from your 24” screen. No! Make it 48” or have several of them. It’s virtual anyway. Ever wanted your emails to be announced just not on your screen because you’re coding now? No problem – they can float off to the left, if you want. Your office can look however you want it.

Just add some pluggable noise-cancelling earphones to the rig (hear that Microsoft? I want to be able to plug noise cancelling earphones into my HoloLens!) and that annoying chatterbox may as well be on the other side of the world, for all of me.

And did I mention the privacy? Nobody looking over your shoulder. They can’t see your (virtual) screen unless you share it.

Oh, and for the bean-counters out there – as soon as this device hits the $2,000 mark, it will probably be cheaper to buy than the desktop, desk and cubicle that your office currently has.

2. One office to rule them all!

Moving on to #2, and moving home from the office. If you, like me, work a few days at the office, a few days at home, and a few days at the local Starbucks (or wherever you choose to water your horses), you know that having a decent laptop and VPN is crucial to get any work done, but you may have to decide between shelling out extra cash for having the same office set up at home as you do at work, or do without the comforts that you have at one location or another. You may decide to buy a decent monitor for home, and the same keyboard, but you are definitely going to have to live without your 2 x 24” setup whenever you go to work at the coffee shop.

Enter the – you guessed – HoloLens! Just lug that HoloLens from your office to home (and even to the coffee shop if you aren’t concerned about looking like a dork), and you can have the exact same office setup anywhere you are.

3. Training and teaching

Ever had to explain to someone else how to do something? Ever had to do that when you were out of reach? 10 miles or half a world away, as is often my case, something always seems to go wrong just as soon as I’m away. The farther I am, the greater the problem. I go to work – any my smart TV cannot connect to the internet, leaving my baby daughter unable to watch her favorite YouTube nursery videos (mainly “Twinkle, twinkle little star”, and “Peanut Butter Jelly Time!”) on the big screen (#FirstWorldProblems). I’m out of state? The thermostat doesn’t turn on the furnace (and it’s below freezing outside). Did I leave the country? The garbage disposal unit won’t work.

My wife is very capable, but I have a bit more of a knack for figuring out what went wrong and how to fix it. I could guide her, if only I could see what she sees, and show her what to do…

Enter – yet again – HoloLens! Skype + some virtual whiteboard tool, and I can see the sink as she does, point out where to stick that screw driver, see what’s happening and adjust my guidance without her having to describe what’s happening. Think Remote Assistance, only outside the computer!

Imagine a doctor training for a complex operation. Just put on the HoloLens and bring up a virtual body. Do the operation 100 times until you get it right, then swap for a real body. Keep the HoloLens on, for real-time guidelines on the procedure…

4. Design!

imageWhen Tony Stark designed his Mark-II suit (yes – that scene in his basement lab), a new era of imagining how we design products – forget flat rendering of 3D objects with blueprints on paper. Let’s have the objects floating in the air right in front of us! Zoom in, zoom out, step inside, turn it around – we can really understand what the design looks.

3D Modelling will be come a much more natural process, and design verification will be much better. We’ll be able to see what something actually looks like before we make it.

And speaking of seeing what something looks like, and speaking of Iron Man, imagine trying on a suit or a dress before you buy it. In the comfort of your own home.

5. P0rn

Let’s not pretend that it won’t change this world.

Closing thoughts

I am mostly psyched up about the first two options! Productivity in the work environment is a key concern for me. I believe that improvements there will ripple out to everything else we do.

I’m sure that there are other amazing ways people can improve whatever is near and dear to their hearts with the aid of augmented reality. What would you do if you had a working and stable version of the HoloLens?

Wednesday, December 3, 2014

Winter is Coming… And I’m fine with it

Today I read an article on TechRepublic about how robots and computers automate more and more roles previously carried out by humans, and how we won’t like what’s left.

We all know what’s coming, manual labor will be replaced by machines, leaving only the jobs that (still) require a human mind. I’m sure you cannot throw a stone without hitting a politician or spokesperson who will tell you that this is bad, but at the risk of coming off as a detached and condescending elitist, I will have to respectfully disagree.

Change Happens

Change happens. Always. This isn’t a new thing. Change has been happening since the beginning of time. Literally. Without change we’d still be a potentially explosive situation in the middle of nothing, because the Big Bang wouldn’t have happened.

Okay. I’ll agree that that was just some demagoguery. Forget everything that happened in the last couple of billions of years. Let’s limit the discussion to technological advances. Disruptive ones. Like agriculture. Advances were being made that changed the world, and the roles humans played in it. It started some 10,000 years ago, and is still going on today. Still not convinced? Still think this is demagoguery? Okay, I’ll put that aside too. Let’s talk “real” technological changes.

How about the Industrial Revolution? Those factories? Them machines sure replaced a lot of people didn’t they? Please note that that was going on some 250 years ago.

Change is a Good Thing

The Japanese word “Kaizen” literally translates to “Good Change”. Now, I’ll say straight up that not all change is good, hence the differentiation, but I believe that it is more often better than it is worse. I don’t have any scientific proof of it, but I seriously doubt that anyone could argue that their lot in life is actually worse than it would be if they were in their comparable station in life in or around 18th century Earth. I think that even people living in 3rd world countries all over the globe are as well of as they’d be, or better. I believe that just being able to discuss their issue, having first world people become aware of 3rd world people is an improvement. We, as a rule are becoming better people.

Please note, that the comparison I am making is between one person, and his or her own lot in a world “stuck” in the past. I believe that inequality, while it is a touchy subject, is irrelevant here. I know that there are people who hunger for bread living a few miles from people who have more money than they could ever spend. But was that not always the case? I believe that I myself, my friends, and probably anyone who has a computer, tablet or smartphone with which to read this post lives better than most nobles did a few centuries ago, and better than any king just a few centuries before that. And I’m just making a (fairly) decent living.

So What is the Problem?

Adapting to change is difficult. Disruptive change, more so. When something that you know, and believe in may become invalidated and obsolete, it may feel overwhelming and scary. Other times it just makes you feel irrelevant – just like your (now useless) knowledge.

People have been losing their jobs to machines since forever, possibly since ten thousand years ago, definitely in the past 250 years. But this isn’t a bad thing!

For every manual laborer whose skills were no longer necessary, two jobs showed up for factory line workers. Old jobs transformed to adapt to the new world. New jobs were created. Some people adapted, others did not. Those of us who adapted were better off for it. Those who didn’t, weren’t. And we can and should feel sorry for them, and that is okay, and it is okay to rejoice in our own improved lot, because the change made our lives better, as a rule, or it wouldn’t have happened.

The issue at hand, I believe is that change itself has changed!

Change is Changing!

Change was always happening, and the rate of change was always increasing. But where in the past change happened over billions of years, until it could be measured in millions of years, and human advancement was then measured in millennia, at some point changes became so great and so quick that we started to notice. The industrial revolution was, I believe, the first such point in time, with change so great and so fast that it one could perceive life before and after it, within one’s own lifetime. Since then the changes began to happen every several decades – factories, the telegraph, automobiles, airplanes, radio, television, computers…

Computers.

From the 1943 legendary statement, (allegedly) made by Thomas J Watson that “there is a world market for maybe five computers”, to a national average (US) of more than five (5.7) internet connected devices per household(!). In 70 years, computers have transformed (almost) everything that we do, allowing us to do more, much more, in less – much less – time. Everything. Including research work. This means that the rate of change itself has changed, dramatically and visibly increasing.

Why, up until roughly 20 years ago, hardly anybody outside colleges had any personal or commercial access to this overgrown, BBS-on-steroids thing called the internet. Ten years ago, I had a palm pilot, had a slow GPRS modem to connect to it, and was the only one I knew that had one such. Seven years ago, the first iPhone came out, and while there were “smart” phones before, it was the first device that was actually accessible for the general population.

Now? More than half of the entire world population have mobile phones. 31.1% of the population have internet access, meaning that just under a third of the people in the world have access to the sum total knowledge of human knowledge(!). Let’s ignore the fact that most people’s usage has nothing to do with knowledge (except in the biblical sense).

The Pros

Is this a good thing? I think it is. For me personally, at least. I cannot imagine being able to do my work, without access to millions of code samples, documentation, tools, guides, online books, etc. Twenty years ago I had to remember most of the software languages that I use, or else take a (heavy) book off the shelf and flip through what I couldn’t remember. Ten years ago I had intellisense and computers had enough memory and disk space for references to be stored on disk for quick access. Today I don’t ever bother to install the help, documentation and SDKs that come with the tools and languages that I use. It is quicker to Google it. Googling even became a word. Almost everybody knows it and does it (except for those who must Baidu it, and those who choose to Bing it, and those elitists who prefer to duck-duck-go it).

The Cons

Some people take exception at this change. From developers who claim that Microsoft-stack coders who rely on intellisense have become crippled by their inability to code without it, to my wife who gets upset because I do not (cannot?) remember anything that isn’t on my calendar, people believe that we who rely on the internet to remember for us have lost something by giving up the skill of memorization.

Personally, I think that a skill that is no longer needed is not worth having except for recreational purposes. I don’t remember how to sheer sheep, gut a fish or skin a rabbit, because I never knew how to do these things. I never needed to learn (though if I did, I’m sure I could Google it).

My main argument is that it is foolish to waste brain power in learning things that will soon become obsolete.

And that is our problem

Changing is Difficult. Not Changing is Fatal

Saw this quote somewhere. It is largely true, I believe. For myself, I love change. I can’t wait to see what the next big thing is, what’s over the horizon? What new technology will come out tomorrow…While I appreciate my own generation’s unique stand point, being born on the cutting edge, riding the wave of technological change, We are immigrants to this brave new world. I would love to have been born today, to be a true child of the millennium, to be born a native child of the world of technology. What does my eldest daughter at 13 feel, never knowing a world without the internet? How will my baby experience the world, growing up in a world where scientific and technological advances I can barely imaging will be common place?

But it is a constant struggle, riding the wave. One must adapt to change quickly, one must learn to devalue what one knows, in favor of what can understand and extrapolate. Hanging on to yesterday will cause you to fall into the chasm with it.

I figured that out on my own. My children will have that engrained in them. But many of my generation don’t understand that. Most of my father’s generation do not. How surprised are we to see our parents have a truly thriving online presence? Our grandparents? I learned to work with computers at an extremely young age, because I saw my father, one of very few at the time, using one, programming. My kids still perceive me as an expert on technology, though I already defer to my daughter in some areas (social networks, mostly).

My mom can operate a computer if told exactly what to do, step by step. I have friends whose mothers can read their email, because they have to, as part of their work, but go to pieces if things don’t work just right, because they fear the computer. Computers are alien to them, and the change they bring is beyond them.

My grandmother, and some uncles will still want to explain to me how to get somewhere, all while I politely explain that I just need the name of a place or an address and Google Maps will do for the rest.

That’s all okay, they have their ways of doing things, and I have my waze.

But not at the workplace.

At the office, at the factory, time is money, and anything that a computer can do, it can do faster and with greater precision than any human can cope to do.

And once a computer can do something, it is only a short matter of time before it will replace a human doing it.

What will such human do?

Learn to do something new, or become extinct, obsolete, unemployed.

The Way of Tomorrow Today

At any job interview, I will tell my would be employer that the biggest asset that I bring is adaptability, my ability to learn, knowing how to know. More than one customer asked me a question, and when he saw me searching the internet for the answer, he or she asked me something to the equivalent of “If you don’t know the answer why am I paying you”? My answer is always a simple statement that I’m paid because I know enough about my domain to Google faster than anyone he or she employs, I know where to search, I can understand what I read faster, and extrapolate a better solution to the problem than anyone else (perhaps a bit arrogant, but selling yourself short is never a good idea, and stammering any other answer would be worse).

What is my point? My point is this, in order to thrive in the world today, one must cultivate the skill of learning in one’s domain of expertise. One must learn to adapt to disruptive change, to seek out these changes and prepare, to look for opportunities to adapt first and come out on top.

That, or fade away. Or hope you can retire before becoming completely obsolete.

I consider myself lucky (though I believe in making my own luck), I could never as a kid sit down in one place at school and learn to retain knowledge I considered useless. I instead learned quickly on my feet, figuring things out in the middle of a test, extrapolating from whatever I learned before. Today this a prized skill.

Others who are less lucky have to learn now. Change will never stop. Not everybody will hold back, and not everybody will stop inventing new ways to replace human labor with computers. Perhaps one day it will all be computers and machines doing the work, and perhaps we can become a utopian society where machines can sustain comfortable human life for all, and people will simply do what ever they can to make themselves and the world better, not for monetary reward, but because they want to fulfill themselves (see – this isn’t communism).

One can hope.

And adapt.

Friday, October 3, 2014

10 Things You Should Know When Submitting a Bug

An on-call technical support engineer wakes up groggily at 2am, when his phone rings. It’s a department manager. “Huhhhh? Huhhlllo?” he mumbles into the phone.
“Your software doesn’t work!” states the angry voice on the other end.
“Uhhh… Could you be more explicit, sir?” asks the still bewildered techy, trying to figure out what’s going on.
“Your software doesn’t #&@<ing work!”
So, that might sound like a joke, but for many people in the software development business, this is just another workday. It seems that whenever somebody has a technical issue, they become even more technically illiterate than they might normally be. Personally, I believe that fear and frustration with their unknown situation, coupled with annoyance at having to deal with a less-than-perfect product reduces the end-user’s ability – perhaps at a subconscious level, perhaps not – to be a part of solving the issue. They want it solved, and they don’t care how.

We want information. INFORMATION!

No, I’m not the new number two. I’m just another developer, who has to solve problems with software, and consequentially, solve problems in the software that solves the problems. I get bug reports coming from end users, testers, middle managers – sometimes even fellow developers – that leave me without anything more than a general sense that there was a disturbance in the force, and the software is not performing within acceptable parameters.

Please understand! Most of us are actually eager to solve problems! A lot of us actually got into this business because we have a hacker mentality, we’re tinkers at heart, and we view every problem as a challenge to meet! Don’t hear us clicking away furiously at our keyboards, guzzling coffee, muttering curse words (often in foreign languages such as Russian or Klingon), and then stop with a resounding “WHOOP!” of joy? That’s a feature we developed or a bug we fixed.
Help us help you.
The items below are the top ten things every developer wants you to provide – as best you can – to help him or her understand what the problem is and how to reproduce the issue:

1 – What do you mean to say?

I know that for many of you, the official language might not be your native one. Where I live, roughly half of the people are foreign-born (which is great, by the way – I like diversity). It’s fine. But please, please, do your best to write your bug report in a precise, understandable manner:
  • Be specific – did you load a file? Fine. Did you click on a button, select from a menu, or did you use a keyboard shortcut? It might be important. For bonus points, try all different ways to do whatever you did. If it works one way and not the other, let the developer know.
  • Be explicit… as in precise. Instead of the ‘it’ pronoun, describe it (‘the window’, the ‘message box’ the ‘radio button’, the ‘phone’, etc. Just not ‘it’).  Use the Find command in your email client, browser, MS Word, or whatever you’re using to report the bug, search for the word ‘it’ and replace it.
    Also, avoid ‘they’, ‘he’, or ‘she’ unless there can be absolutely no doubt about the person’s identity.
  • Reread what you wrote – unless you’re completely incompetent as a writer in the language in which you’re writing (and I guess it’s okay, if they hired you despite your language deficiency), you should be able to see if you think that you were clear. If you weren’t, please correct your grammar. And for the love of your chosen deity, please use a spellchecker. Correct those squiggly red lines!

2 – Can I please have a bug report, hold the attitude?

Jokes aside, we usually do not insert bugs into the system intentionally. At best it was the one defect that slipped the developers’ scrutiny. Often it is the product of being rushed to meet a tight deadline. At worst it is the result of negligent work born of the despair of either not knowing how to work properly and worse – knowing how things should be done, but not being able to do them the right way (see aforementioned deadline).
Either the poor developer is mortified by the bug (extreme unhealthy reaction – but it happens), or the developer has become apathetic to the bug through continual disillusionment (extreme unhealthy reaction – especially for the organization that employs him or her), or anything in the middle.
There is no point on the reaction scale at which berating or verbally abusing the developer is productive. Or even acceptable.
So take a deep breath and stick to the facts, Mack!

3 – What exactly seems to be the problem?

imageNo, we don’t think that you’re making it up, that you’re dense, or that you’re bothering us with trivialities. We just want to know what kind of a bug you might be dealing with now:

  • Did you get a weird error message?
  • Did the application crash (i.e. suddenly shut down)?
  • Did the application freeze?
  • Does something look wrong?
  • Is something missing?

4 – Do you have any evidence?

Yes, for god’s sake, we believe you. We don’t think that you’re off your rocker, if you have one. We need whatever evidence you have to help us identify the problem, find its source, and resolve it. So if you have it, give it up:
  • Screenshot of the problem
  • Exact wording of the error message
  • Log file (if you don’t know what that is, don’t worry)
  • Any other kind of output?
Also, if you’re a tester, please come prepared – you’re working with software, our software, and you know it might malfunction.In fact, if it didn’t, you wouldn’t have a job, now, would you? Since that is the case, please have some kind of diagnostic tools installed to help you gather the evidence: loggers, video captures of your testing session, etc.

5 – Do you have any special set up or configuration?

Especially if you are a developer or tester, you might have a special configuration file with specific setting that you are using. Please provide any non-sensitive configuration, or at least describe it. Anything you know about how you use the software can shorten the time it takes to fix the problem.

6 – What did you expect to happen?

No, it’s not a cynical way of stating that that’s the way the cookie crumbles. We don’t always know what you believe the normal behavior should be. You may be right, you may be wrong. If you’re right, we need to fix it. If you’re wrong (i.e. the infamous “not a bug”, a.k.a. “by design” / “as designed”), we need to fix our documentation. So please let us know what you expect.

7 – What did you do before the problems started?

horrified pupLemme guess: You think that it is your fault. Well, it isn’t. Period. It never is. Get over yourself. Stop wallowing in self pity and shame. This is me being cynical and stating that that’s the way the cookie crumbles. Nothing but the simplest programs can ever be completely defect-free.
What we mean to ask is “Can you please tell what steps I need to take in order to reproduce this myself”?
So please, list the steps you took, as best you can, so that we can repeat those, as many times as necessary, until we find the problematic part of the code that needs to be fixed. It is usually something in the code that is responsible for handling the steps you took, so this information is vital!
This is where a video recording, coupled with a log file and input recording would be nice. Testers – please use those.

8 – It works fine on my machine.

Okay, this one goes out to all you developers out there. There is nothing our coworkers hate hearing from us more than this line. It is not okay. It is still your responsibility to resolve the problem. I once worked with a manager that suggested that any developer that shrugs a defect off with “it works fine on my machine”, will be shipped off to the customer with his machine, in order to solve the problem. Said customer was in another country, where summer temperatures reached over 50 degrees Celsius (122°F!).  To my knowledge the threat was never actually carried out, but the developers there used the phrase less than any other team I’ve worked with.
What we mean (at least what I mean), and what we should say is “It works fine on my machine. This means that the problem is probably related to your environment. Can you please describe the conditions in which you are running this software?”.
So please describe your execution environment (re: what your machine is like), to the best of your knowledge. If you don’t know it, don’t sweat it – but if you are a non-technical user, and can find out this information (Wikipedia is a good enough explanation. You don’t need a PhD to understand most of it), you’ll really make your developer’s day:
  • What version of our software do you have? Testers – you must know this. Devs – you must make this knowledge available!
  • What are you running this on (smartphone, tablet, laptop, PC, server, virtual machine)?
  • What operating system are you on – we might not know (Windows, Linux, Mac OSX, iOS, Android, Samsung? etc.)
  • What version of the operating system do you have (Windows XP, 7, 8, 8.1, Mac OS 10.6, 10.7, 10.8, 10.9, iOS 6/7/8, Android 2.2/2.3/4.0/4.1/4.2)?
  • What version of Office do you have (if any)? It may be relevant.
  • If you know the software to be a sub-module or extension of some other software, please let us know what version of the host software do you have (e.g. you’re running an extension on Visual Studio – is it 2010/2012/2013? Which update?)
  • If this is a web application, what browser are you using? What version?
  • How much memory does your device have?
  • How much free disk space does it have? All disks / volumes, please.
  • Screen size?

9 – Are there any specific conditions / times that this happens?

Sometimes a bug will consistently appear whenever the application is executed. In other cases it might be limited to happening only sporadically:

  • Does it happen every time you run it?
  • Only every other time? Third time?
  • Only mornings?
  • Every Sunday at 2am? This is not a joke. If I know that the nightly backup happens at that exact time, I can deduce that the two events are interacting and this causes the problem.
  • Does it happen only when some file is open in notepad?
  • Does it appear to be completely random?

10 – Is this happening to anyone else, as far as you know?

This one goes especially for corporate and enterprise users, as well as testers in teams. Nobody expects Joe Six-Pack to go knocking on doors in order to figure out if he’s special or part of something bigger.
By now, you probably know that I’m not singling you out as an idiot, or something, but rather want to understand what is happening. If this is happening to everyone on your floor (but nowhere else), it might be some network issue. If it is only you, it might be a configuration issue, but if everyone on your team who’s using Internet Explorer 10, as opposed to 8, we know that there’s a compatibility issue in the code. The developers need to be able to identifying what is common to those who have the problem, that sets them apart from those who do not have it. It’s called differential diagnosis.
See, every bit helps. If you’re on a team, you really could go that extra mile to see if your teammates have similar issues. Especially if the software is built by the same company that you’re working for. You’re all in this together.

In Conclusion

We’re all in this together – developers, testers, operations – we usually (should) have the same interest – to make sure that we create a better product. So please – pretty please – with relish(!): be professional.

Thanks in advance,
Assaf – a developer.

Monday, January 6, 2014

12 Revs of Software

Would you put your gifts under this?A Version from St. Service Bus

’Twas the week O’releasing, and all through the teams,
Not a programmer testing, at least so it seems.
The builds barely holding, the crashes abound,
In hopes that some luck, or a safe place be found...

[Enter the choir. You can sing along. You know you want to…]

The Twelve Revs of Software

BadSoftwareSnakeDMOn the first rev of software, my dev team dropped on me
A piece of software that I can't release.

On the second rev of software, my dev team dropped on me
Two breaking smoke tests,
And a piece of software that I can't release.

On the third rev of software, my dev team dropped on me
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the fourth rev of software, my dev team dropped on me
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

bug_report-250x250On the fifth rev of software, my dev team dropped on me
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the sixth rev of software, my dev team dropped on me
Six missing specs,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

angry-bossOn the seventh rev of software, my dev team dropped on me
Seven bosses angry,
Six missing specs,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the eighth rev of software, my dev team dropped on me
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the ninth rev of software, my dev team dropped on me
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

clip-art-waitingOn the tenth rev of software, my dev team dropped on me
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the eleventh rev of software, my dev team dropped on me
Eleven builds a-crashing,
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release.

On the twelfth rev of software, my dev team dropped on me
Twelve months were wasted,
Eleven builds a-crashing,
Ten seconds lagging,
Nine queries locking,
Eight devs on sick leave,
Seven bosses angry,
Six specs a-missing,
Five bugs regressing,
Four tests a-failing,
Three days till deadline,
Two breaking smoke tests,
And a piece of software that I can't release...

Youre-Fired1Final Round...

He sent résumés, to his team gave a whistle,
“This product is dead”, he said this Fo’shizzle.
If you do it at all, then perhaps do it right.
Happy coding to all, and to all a good night!

 

 

 

 

 

A very special thank you to my good friend Maor, who reviewed, QAed and wrote the first verse of the Version of St. Service Bus.

P.S.

This post was supposed to go up on Monday, before Christmas Eve. Unfortunately, I, too, missed my deadline.

Happy New Year.

P.S. 2

My New Year’s Resolution is Retina.

Sunday, January 6, 2013

Patterns of Testable Software

Patterns of Testable SoftwareMy love for test driven development started a few years ago, when I first had a taste of it while working on a product in a startup company. I started out using TypeMock, a really wonderful framework that allows you to isolate the code you want to test from its external dependencies, without having to change the way your code is designed. Within a few months, my team and I completed our work, met our deadline, and we were confident in the product, because we had tests to prove that it works.

Writing Unit Tests is Easy! Good Tests… Less so

Writing unit tests is easy. All you have to do is choose a single use-case of a method that you’re going to test, set up its inputs, and measure the output against some expected result. If it matches, then the test passed. If not, it fails. Rinse and repeat.

Our problems started after that. With the next version, we had to modify our code. No problem, we thought. Our code has unit tests. We can refactor without fear, because our tests will tell us if we’re breaking anything. Except it didn’t. Because of the way our software was written, and because of the way we mocked our dependencies, our tests were tied in to the implementation of the code, rather than the end results. This meant that our tests were brittle, and fragile, because the tests broke whenever we changed our internal implementation. Our tests were starting to “cry wolf”. We abandoned them quickly.

As it turns out, it is not enough “just” to write tests. You actually have to write the production code in a way that is easily testable. Your code has to be written in such a way that you can verify the outcome of a method without depending on internal implementation details. As time passed, I became more and more proficient at doing this, while becoming increasingly frustrated at the difficulties that beginners have. I see many good programmers giving up early, because the tests fail them, because it is difficult to get existing (legacy) code under a good test harness, and because they keep hitting a wall with the question of “how do I test this?”.

Patterns of Testable Software

I have recently begun trying to codify recurring patterns of software that is easily testable: Patterns that developers should strive to conform to, or refactor their code to. Patterns that help developers test the state of a module after running it, as well as to test the behavior of the module when running. Patterns that test the outcome without depending on implementation details.

On Thursday, January 24th, 2013, I am going to present some of these patterns for the first time, at the Toronto ALM User Group. At the time of this writing, there are still some open spots. If you’re in the neighborhood, and are interested in Test Driven Development or writing unit tests in general, I think that you’ll find the material quite rewarding. You may register for free at http://www.meetup.com/Toronto-ALM-User-Group/events/97454932/

I hope to see you there and if I do, I hope you’ll enjoy the session.

Assaf

P.S. Oh, and happy new year!

Tuesday, August 21, 2012

Windows 8 RTM is Available for Evaluation

imageIf you haven’t been living under a rock, then you probably heard of Windows 8. It’s new, it’s different, it moved your cheese to a different time zone.

And it’s freely available for a 90 day evaluation!

You can download the Enterprise edition here.

A few things to note before you try it:

  • This evaluation cannot be upgraded!
  • You will have to install a retail version of Windows when the trial period is over! Don’t say I didn’t warn you…
  • To revert to a previous version of Windows (say, Win-7), you’ll have to do a clean install.

You may wish to try installing it on a virtual machine for evaluation. Personally, I’m partial to Virtual Box, though you can of course create one with any platform.

I’ve already installed it. So far, so good. Everything but my Dell’s fingerprint reader works. Grrrr….