About Rajen Mehta

Retired CIO - City of Buffalo. MS (Mathematics) from University of New Delhi India, MBA (From University at Buffalo).

Why Software Developers Make Good Spouses

 I often envy my wife because she married a software developer. She doesn’t realize how lucky she is! Come to think of it, I think everyone married to a software developer should applaud themselves for their wonderful choice.

Why am I being so boisterous about the idea of software developers as an ideal spouse?   I can give you thousands of reasons but, unless you’re a developer yourself, you probably won’t have the patience to read them all. So, I narrowed it down to the top 5:

 1.  They don’t mind being nagged:    

Developers like to build alerts into their software. Alerts to call them, text them, or interrupt them with a popup message.   They want to be alerted when something goes wrong, when something unusual happens, or simply, when the software completes a step. They build these alerts because they care and they love to be told when something needs to attention. So, if you are married to a software developer, nag away. If you are looking for a suitor and would like someone who won’t mind being nagged, narrow your search to developers only.

 2.  They like being told when they are wrong:  

Developers always like to trap for errors. They don’t rest until their software takes care of every possible error. They also make sure they log every error that occurs. No, it’s not that they love their mistakes. As I mentioned above, they just want to know if something went wrong so they can attend to it. If you have uncontrollable urges to tell people when they’re wrong, you should definitely look for a software developer as your life partner. Even if you’re just a casual observer who happens to have a keen eye for spotting mistakes, you should only look for software developers when searching match.com

 3.  They want to keep improving:

Developers love to release new and improved versions of their software. They feel obligated to add new features and improve existing functions and they usually release these new versions on a self-imposed cycle. If there’s nothing to improve, they’ll find something, even if it’s just updating the “look and feel.” Wouldn’t you love to have a spouse who wants to keep improving? Improving how they behave; improving how they look? It’s like marrying a “6” on a scale of 1 to 10 and watching them become a “10” in few years. How could you resist a prospect like that?

 4.  They know how to use all the new electronic gadgets:

Developers don’t shy away from switching to the latest smart phone. And they don’t hesitate to buy that new smart TV or replace that old computer. You can have the latest and the greatest gadgets just because you married a software developer! You’ll be the coolest kid in your group of friends! Go ahead…Brag about having all your music and videos in “the cloud” and being able to access them from your phone, tablet, home computer, work computer, TV, and even your new multi-function wrist watch. You’ll be as tech savvy as you want (and then some) with a software developer as your significant other. Are you one of those people who wanders around looking for an available computer you can check email or Facebook on? Stop wasting your time and marry a developer already. You’ll be connected, informed, and up to date, 24×7.

 5.  They can think…And they actually like to:

Don’t you just cringe when talking to someone who uses blunt phrases in response to your well-worded, profound statements? It’s the worst! If you like responses that are well thought-out, fully explained, and logical then you should limit yourself to only conversing with software developers. They’ll always give you precise, detailed answers and will be able to quote facts to support their opinions! Developers love Googling for answers (of course, we do…Google was built by developers!). If you overhear someone at a party proudly brag that their spouse “knows it all” you can bet they’re married to a software developer!

Live happily ever after…

I’m sure you can now can see what a wonderful life that awaits you if you choose to spend yours with a software developer. If you’re young, eligible, and smart, don’t settle for a boring business person, banker, fashion designer, athlete, or super model–find yourself a software developer and you’ll live happily ever after. Just ask my lucky, lucky wife!

Problems Don’t Float

Software developers have access to helpful debugging tools that let us step through the logic of our code and discover lines of code that might be misbehaving or causing problems. If our code is generating an error, the debugger will tell us which line of code is at fault. If we know our data, we know what results to expect and we can work through the code to diagnose problems if we don’t get the expected results.

Diagnosing problems during software development is relatively easy. The real challenge comes when your software is in operation and the end user has an issue–users report the effects of a problem and we, as developers, have to diagnose the root of the problem from the user’s description.

In the health care industry, they often remind doctors to cure the disease, not the symptoms. The same should apply to software developers; it’s very easy to get mislead by symptoms. My favorite “explanation” from an end user is “It worked before and now it’s not working.” This vague statement always sends developers down a path of investigating what changed between when the software worked and when it didn’t. Often, this investigation turns out to be a waste of time.

Let me give you some real life examples of being led down the wrong path thanks to the wrong focus:

My friend, a staff engineer for Delphi, had to diagnose a problem with overheating vehicles. The company’s customer service staff analyzed all the issues reported and came to the conclusion that most of the cars reporting the overheating problem were yellow in color. The engineering department was misled down the path of studying whether paint color had an effect on the temperature of a vehicle’s engine. Later, they discovered that the overheating was caused when the vehicle’s engines idled for too many hours during the day. Many of the cars that reported the problem were cabs in New York City. Since most of the cabs spend a fair amount of time idling while waiting for passengers and most NYC cabs are yellow, the customer service team’s analysis of the situation was accurate (many cars with overheating issues were the same color) but it didn’t get to the root of the problem (idling time).

I once wrote an application for processing reversal of payment transactions. After the application was in use for a while I received complaints that it didn’t work when processing reversals that resulted from bounced checks. I knew I’d tested for this scenario, so I was upset to learn that something was going wrong in its “real life” use. I found out later that a new staff member had been assigned to process the bounced check reversals. This new employee wasn’t properly trained and was mistakenly entering check numbers in the account number column, and vice versa. The problem wasn’t with bounced checks; it was user error. But I wasted a lot of time researching the bounced check stuff before we discovered the real issue.

This leads me to a line one of my Operational Analysis professors used to use: “Problems don’t float, only their effects come to the surface.” Don’t get misled by how a problem is described to you, instead do your own investigation; build your own understanding. Don’t just skim the surface; you have to dive deep if you want to find the root cause of a problem.

Here are few basic steps I’ve always found helpful when diving deep:

1. Collect examples of where the application malfunctioned and make sure you don’t limit the examples based on how the problem was defined to you. Do some analysis of your own to see which data sets produced the wrong results.

2. Compare the data to the source document to eliminate any data entry issues. Don’t assume anything. I remember one application where data fields were mislabeled during a configuration step, causing the wrong data to appear in the wrong columns.

3. Make sure that business requirements haven’t changed. Try not to offend the user reporting the problem, but make sure the output they expected matches the business requirements you followed to build the application. I remember an instance where a payroll auditor held back hundreds of paychecks, declaring that salary calculations were wrong. Many hours were wasted verifying the software used to process the calculations, only to discover that the payroll auditor hadn’t been informed that pay raises had gone into effect.

4. Work through the application using the data from the examples you collected. Make sure each step of the way that the output matches the business requirements. Again don’t assume anything, work through each and every step. Not only will this help you diagnose the problem reported, you might discover some other malfunction that was overlooked during development time.

And finally, remember that once you do uncover the root of the problem, you congratulate the end user for discovering that special “hidden feature” in your application!

Conservative Values of Software Development

I have been associated with software development for over 35 years. I wrote my first software using assembly language. Every thing that executed in our software in those days was written by us. We did not have libraries to link to or objects to include or API’s to call. I am not trying to imply that software development is easier now than it was before. The challenges faced by today’s developer are different than what we faced. Software written in those days accomplished less with more lines of codes than today’s software. The technologies, methods and many other aspects of software development may have changed but the basic rules that we followed those days still hold value.
Let me introduce you to those basic rules that I always followed. I call them the conservative values of software development.

Keep it simple:

One of my professors of assembly language programming gave us a challenge as our first assignment. We had to write a simple program to determine if a given number was prime using a pseudo language which contained only one executable statement and one declarative statement. It took us hundreds of lines of code to accomplish that simple task. The lecture that followed that assignment taught me a life long lesson: Simple programs are easy to debug, easy to follow, and usually more efficient to execute. Writing a complex line of code that can accomplish several tasks may make you feel good about your coding skills but pray that no one else has to debug or change that code some day, because they won’t agree that you’re a good coder. Accomplishing the same set of tasks in few simple lines of code will be better in the long run. Simple code is more readily reusable. I’m not preaching that you shouldn’t use all the tools at your disposal, just that you should remember to keep it simple.

Don’t lose focus on your target users:

This rule is more applicable to today’s developers because we use so many different apps in our day to day lives that using software becomes a second nature to us and we start developing our software to behave the way we want our software to behave, which can lead to many assumptions and prejudices of user requirements on our part. You’ll only work once to build the software but the user will use it many, many times to help them take care of some important business. Your number one goal should be to make sure that they can accomplish the tasks important to them in most efficient and simple steps. They might be wowed by fancy features the first few times they interact with your software but, in the long run, its efficiency and ease of use will be the only things that will matter.

Making your software mistake proof:

Making assumptions about a user’s requirements is as bad as assuming that all users of your software know what they are doing. Yes, they do know their business and probably know what they want to accomplish but you can’t expect them to always enter the right values in the right fields and chose the right action. But you shouldn’t attribute their mistakes to lack of knowledge, repetition can often create “slip-ups” and if little mistakes create a lot of “fix it” work, then failure isn’t just theirs but your software’s, as well. You know the business rules and you know what mistakes can corrupt the data or corrupt the process–put in the extra effort to edit for those mistakes. Your users may not realize it, or even appreciate it, but you’ll create a more efficient process for them and that should always be your goal.

Software Developers are like people who build roads. Basically, we’re providing a means to get from Point A to Point B in the most direct way, saving our users time and hassles.   Remember not to build a scenic road, full of curves and bumps, if you’re building it for drivers who use it to get to work every day!