Things I Wish I’d Known Preparing for Ground Truth – Part 1

Since our founding in 1998, Algonquin Studios has acted as a trusted ally for several startups and has even launched a few businesses ourselves. By March, 2010, several Algonquin Studios team members had built a robust hardware prototype: a mesh network of sensors, controllers, and management software. It personalized the environment and access within commercial buildings and hotels. But the team had limited sales and installation experience.

Coincidentally, I had a trip to Beijing and Shanghai forming, as my team needed a capstone project in the University at Buffalo’s Executive MBA program. What a lucky match! Beijing and Shanghai were saddled with surplus real estate following the Olympics and investment booms and firms were hungry for smart competitive advantages. Why wouldn’t this solution work in China? My team set up in-person demonstrations and feedback sessions with hotel and property managers while we were in China, and brought back a trove of on-the-ground observations.

We were surprised at what we learned and the ways that were identified for doing things better the next time around. I’m sure you would be too:

Is that a prototype or a bomb? We brought several black plastic boxes as functional prototypes. Each was the size of a juice box and had LED lights and wires hanging out the side to batteries. Frankly, they looked like bombs to our American eyes. How would we get them through customs in China? It turns out they didn’t care.

Demos will break. How many ways can you give your demo? It had better be a bunch. At our first meeting we fried the Radio Shack step-down transformer we brought with us. But we had rehearsed in the hotel – how unfair! So what? We couldn’t find another transformer in any store. We would have been stuck giving vaporware demos, and our surveys would have just measured the dream in someone’s head. But, we found a way out – powering up with batteries or laptop USB ports. In fact, laptop wall power supplies adjusted to every location with just a reliable plug adapter and laptops could be recharged, unlike plain batteries.

Tricky Demos = No Demos. The developers warned us that the devices would jump to a different port every time we started a demo. My background is development, so I could resolve the problem without anyone noticing. But the rest of my team struggled when we split the team up to do two meetings at the same time. Remember, your goal on the ground is to get feedback and the talent you’ll have won’t necessarily be technical.

What does ‘done’ mean? Following that thought, we realized our demos could have been more polished. We built our demo around what the developers showed us. Why not build it around what evokes meaningful feedback? For that matter, make it look good so you’re not distracting prospects with a bomb, highlighting how far you are from done, and maybe getting them to feel like they should work with a cool outfit like yours.

How will you pay for that? Business credit was new in China in 2010; most paid by bank transfer or online services like AliPay and TenPay. Not one of our prospects chose credit cards as a possible payment method. One kind soul wrote, “There are no credit cards in China.” We could have figured that out from a few web searches, but we didn’t do the due diligence. So, did we miss a chance to get better feedback?

Integration and Management Services. Don’t forget that a hardware solution lives in an existing context. Every one of our prospects asked how we would work with their existing systems and offer administrative tools. If you can’t do this yourself, it’s smart to partner with a firm such as Algonquin Studios.

Sales Channels. Who will your prospects buy from? Our prospects suggested that we partner with a US firm already established in China, increasing trust, avoiding intellectual property theft, and offering integration options. Even a two-person local sales team with an engineer would be better than selling from outside China. You might need local help to get products out of customs delays in port.

Each building is an island. Treat each prospect as a unique case. We met with hotels and property managers, very concrete examples. We were surprised to find that each hotel provided its own utilities and services, including massive electric, water purifying, and emergency outfits. Less literally, don’t make assumptions about the rules. Listen first.

Even if you’ll open your business in your home market, or your foreign market is in the west, there’s more to ground research than just product demos. In fact, we wouldn’t have gotten any feedback without adapting on the fly. How thrilling!

Stayed tuned for Part 2 of this post, which will cover our take-aways on the more “personal” aspects of cross-cultural market research.

Related links that rang true to me:

Tips for On-the-Ground Market Research
Global Health at MIT

Ground Truth and the Importance of Market Research
Karyn Greenstreet

Ground Truth
NASA

Consistency is Key!

A successful software development project is one that maintains consistency.

Whenever I visit a site or application that lacks consistency, it makes me uncomfortable. If each page acts differently from the others, it can end up confusing the user and feeling and looking poorly developed and unprofessional. A good development coding standard can help ensure a high level of consistency throughout an application and, once in place, these standards need to be followed. In the end, a good developer needs to make sure his/her final output reflects the standards and is built in a consistent, user-friendly way.

Another reason to adhere to a consistent, standard approach when developing a new application? Without it, the ongoing maintenance of the application will become cumbersome. If five developers are all coding differently, in their own style, you’ll eventually end up with an application that won’t lend itself to easy maintenance and might not function properly in the long run.

Remember, software often ends up being maintained by people who weren’t involved in the initial development of it! If you’ve ever been responsible for the upkeep on an application that was built with little adherence to quality standards, you know—it’s no fun! If the cost to upgrade or improve an inconsistent application becomes too high, it could force the client in a different direction.

I remember supporting an old ASP 3.0 application that was generally using the same connection information in a standard configuration file but had a few forms using hard coded values for the connection information. I couldn’t understand why, all of the sudden, some of these were breaking when my database information changed. This should have been a quick change to the configuration file, but turned out to be a pain!

When building front-end user interfaces, make sure you’re putting on your “end user” hat before you start working. When building out forms, do so in a consistent manner. If you have grids with search results on a screen, make sure all those grids are reporting the same data, and the same options, in the same way. Make sure all dates are displayed in the same format. All numeric/monetary fields should display consistently. Buttons with the same underlying logic should have labels that are consistent so the user can understand, from screen to screen, that button does the same job or accomplishes the same function. Make sure your form controls are organized in a pleasant manner—one that’s easy on the eyes and that can be tabbed through quickly. If it’s a data entry screen that users will be spending hours on each day, make sure the controls are aligned and sized properly allowing users to keep their focus on one part of the screen and providing a better overall user experience.

Before you start developing, take a look around! Review some of the screens in the system—there should be a common theme to the user interface; follow the same approach. Take a look at messaging and make sure you’re reporting information to end users in the same way. It won’t take long to get familiar with the site and then, once you start building your new feature, you’ll have a good context as to what it should look like. When you’re done developing, the new feature should look like existing ones.

One last note when testing your development—people still use IE! Do some browser testing to make sure your site is looking good and functioning well in the major browsers. If you’re only developing and testing only in your personal favorite, you’re not doing a full test. Sometimes, there are specific client requirements for the system you’re working on, so be sure you know what they are before you start. Some internal applications are written strictly for IE. Are there mobile requirements for this application? If so, be sure you’re testing those as well.

In the end, making sure your software development is done in a consistent matter is better for everyone in the long run. It will ensure the end product looks and feels like a well thought-out, professional piece of work!

K.I.S.S.

Nope, I’m not talking about extravagant costumes, black and white face paint, and fire breathing.

I’m here to discuss the old adage “Keep it simple, stupid” and how it applies to software development.

As a Project Manager, I spend a lot of time meeting with clients to review requirements for their software and work with them to turn those requirements into a full system. As I work with my clients to navigate the treacherous waters of system design, we inevitably end up with a “feature” that we all agree is on the borderline of “Necessary” and “Nice to have.” This is especially hard to determine in a business system that users will be working with every day.

This is when things get interesting! Let’s take a look at what questions to ask yourself:

Why do you want this feature?

You can tell a lot about how important this feature really is by the initial reaction of a client when you ask this question. If it takes a few minutes of fumbling to eek out a satisfactory answer, you can most likely scrap the feature.

Is it worth it?

To answer this one, we’ll ask a few follow up questions, too:

  • How often will this feature be used?
  • Is there a manual workaround that can be used instead of this feature?
  • Who will use this feature (and how many of these users are there)?
  • How much work will be created for a user is this feature is left off?

Now do a little quick math and, magically, we can determine if it’s financially worth adding this feature. Here is an example:

Add this monthly report that aggregates data for X, Y and Z. 
  • Feature will be used monthly
  • User can perform this process manually
  • 1 administrative user will use the report
  • If this feature isn’t implemented, the administrative user will need to run 3 reports and aggregate the data themselves. This process will take approx. 20 minutes.

Answer: If building the report adds 8 hours to the system build, it will pay for itself in 2 years.

Does this feature add complexity to other areas of the system?

I’ll let you in on a little secret, the answer to this question is always YES.

No mater how much you want this fancy new feature, it will make your system more complex. We often try to convince ourselves that a feature is so simple that it won’t add complexity, but there are a couple of points that always hold true:

  • This feature will need to be tested after every update.
  • The users of this feature will need training.
  • This feature will need to be documented in the help system (and maintained).
  • This feature will need to be discussed when future changes to the system are designed/implemented.

So, let’s return to our seemingly simple example report and apply these issues to the “complexity” question:

  • Will this report need to be tested? Yes
  • Will the users need training? Yes
  • Will we need to add help documentation? Yes
  • Will this report need to be updated if we make changes to report X, Y or Z? Yes

There’s no doubt about it–every time you want to add a feature, you’re choosing to make the system more complex.

Before you commit to a feature, ask yourself if it’s a system requirement and make sure you really understand, and accept, the increase in time, complexity, and cost that including the feature will entail. If the answer is “yes,” then let’s build it. But if there’s any doubt, remember, it’s never a bad idea to K.I.S.S.

Making a Good “First” Impression

There’s nothing like the old cliché, “You never get a second chance to make a first impression.” In the software development business, this quote definitely holds true. Earning a client’s trust will hopefully happen the first time you meet with them to discuss their problem and work to identify a business solution, but once you gain that trust and come to an agreement to help them achieve their business solution, it doesn’t stop there. There are other points during a project that provide an opportunity to make a good impression, to ensure a successful project, and a great client relationship in the future:

Project Kickoff Meeting

At the start of the project we usually conduct a project kick-off meeting. Sometimes this meeting is with your initial contact, on whom you’ve already made a good first impression (or you wouldn’t have the job), but often this meeting will introduce you to the client contact who you’ll work with throughout the course of the project. It’s important to convey, during this meeting, that you understand the company’s needs and that you’re willing to listen to their ideas, suggestions, and pain points. Here are a few examples of what I do in these meetings to help ensure I’m making a good impression:

  1. Come organized and be prepared. Make sure the client knows that you understand their problem.
  2. Ask questions and don’t assume you know any answers. You’ve got questions for a reason; assuming the answers will ultimately leave you lacking vital information you’ll need later on.
  3. Listen to what the client wants and, if what they explain doesn’t make sense, see if you exlpore new ways of “explaining it” with them. I often have clients draw what they want on a whiteboard. While the drawing might not be an accurate representation of what will be needed in the long haul, having the client take control and talk things out while sketching is a good way to get them to focus on the goals of the project and gives you a great opportunity to gather requirements.
  4. Be sure someone from your team is taking diligent notes that you can refer to after the meeting and throughout the course of the project, making sure nothing gets missed.
  5. After the meeting, send the client an email, summarizing all the details and plans that were discussed.

First Client Demo

One of my favorite things about the software development process is seeing the client’s reaction when you first show off the solution you’ll be providing. Depending on the size of the project, and how many meetings it took to fully gather the requirements, the amount of time between kick-off to the first demo could be months-a lot of hard work goes into the requirements and construction, so you don’t want this first demo to go poorly. Having a bad demo might strip their confidence in you and what you’ve been striving to achieve with them. Here are some suggestions that have helped me ensure a great initial demo:

  1. Manage the client’s expectations about what they’ll see in the demo prior to arriving for your meeting. If you don’t know what to expect, they might be disappointed when that “cool feature” they’re all waiting for isn’t quite done.
  2. Try not to demo something that isn’t believed to be fully developed. Works-in-progress will probably throw errors and not perform to expectation, so save them for next time, when they are done!
  3. Try to populate the demonstration to utilize data that the client will understand. This may seem subtle to the developers, but having the client understand exactly what they are looking at will generate more productive questions and weed out unnecessary ones. If the client is fixated on “Why do all the fields say ‘Testing A’?” they won’t be focusing on whether you’ve accomplished the task at hand.
  4. For each screen or process you review, be sure to ask if it makes sense and take note of the reaction of the customers. It is usually pretty easy to tell from their expressions whether or not they “get” what you just showed them. Don’t underestimate this step-if you go through an entire demo without offering an opportunity for questions you’ve probably lost them.

As you can see, there are at least three different times where you need to make a good “first impression” throughout a project. This idea has been hammered home to me recently in my personal life, as well, as I’ve interacted with two separate businesses where my first impression of them was less than impressive. I thought to myself “Why would I spend my money on a product when I don’t have confidence that my best interests aren’t being considered?” Make sure you’re considering your clients’ best interests when working on projects for them and make sure the impression you’re providing leaves them confident you’re doing just that-putting them first!

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!

The Importance of Understanding the Big Picture

Many of us work Monday through Friday at breakneck speeds, trying our best to meet deadlines and produce quality code, with the ultimate goal being to deliver great products and services to our clients. For me, the feeling of accomplishment that I get when I complete a large task is one of the most rewarding aspects of software development.

And, while accomplishment is a great feeling, there’s a related phenomenon I’ve struggled with over the course of my 10-month tenure here at Algonquin Studios, and it’s what I like to call “tunnel vision.”

Imagine attempting to paint a twenty-foot wide mural without ever standing more than three inches from your canvas. Since you are so close, you’re able to add extra detail, and maybe even come up with new ideas while you’re working on the small section of the painting. But, what does this painting look like in the end, you might ask? Up close, the individual components of the painting appear beautifully intricate. However, if you step back twenty feet and look at the entire painting, you might realize that you accidentally have half of the people in the scene looking in the wrong direction or perhaps you gave someone two left hands. When you are in this tunnel vision state, you’re so focused on your task that you feel productive and it isn’t until you actually step back and look at the big picture that you realize the glaring mistakes staring you right in the face that will likely end up costing you time and resources.

So enough about painting, what exactly am I getting at here?

If we take this painting example, and apply it to any software development project, there are clear similarities. For example, if you have a large development team working on a project that’s estimated to take several years to complete, it’s easy to sit and simply focus on your task at hand. The issue is that, just like the painter I referenced earlier, your task may appear perfect up close but when you take a step back and look at how it fits into the rest of the system you may realize that things aren’t as peachy as you thought they were.  Maybe you’ve missed an opportunity to collaborate with someone who could’ve given you insight into how to better complete your task.Or perhaps you’ll realize that the extra functionality you implemented (which made sense to you at the time) actually breaks a significant part of the system or will require a significant amount of additional testing. Even something as mundane and simple as changing a database table column name can have a rippling effect throughout the entire system. These things can cost a project time and time is money.

It’s clear that we need a way to recognize when we’re experiencing tunnel vision and find ways to eliminate it.

Here at Algonquin Studios, we might take a quick run up to the seventh floor, just to get our blood pumping a bit. Others simply take a few minutes to sit on a couch and read a book. In the rarest of cases, we’ll watch cat videos on YouTube. Even simple things like these can help clear your mind of distractions and stay focused on the big picture, ultimately improving your productivity and making you a more effective developer.

Do you ever experience tunnel vision? Have you managed to defeat it?  If so, leave me a comment with some of your favorite techniques. It’s certainly an issue that I struggle with on a daily basis and I’m sure that I’m not alone.

Code Reuse: a Blessing or a Burden?

In the world of development, coders are constantly faced with the problem of creating efficient code under a very tight deadline. The idea of Code Reuse, simply the use of code created by another developer, has been a staple concept in the world of programming since the start of development. Whether it is an open-source library or code written by a stranger on a frequently-visited forum, every developer has utilized code reuse at one point. Code reuse definitely has its place in development, but should we rely so heavily on this model?

The first thing you need to think about before using someone else’s code is, “Do I have the right to use this code?” It’s becoming commonplace to see a lawsuit based on one company stealing code or concepts from another. But, beyond the legal reasons against using other’s proprietary code, there are also the ethical obligations that everyone should consider for leaving this code alone. No developer wants their own work to be stolen, so it’s also their responsibility to not steal code that doesn’t belong to them.

Not all code is proprietary though. There are entire communities that revolve around open-source libraries, made to benefit everyone. Here at Algonquin Studios, we have a monthly meeting during which all of the developers get together and talk about the technology they either are working on or want to work on. Our last meeting was based around third-party solutions and not “reinventing the wheel.” If there are solutions to your problem already in existence, why should you waste the time of your employers and clients?

I agree with the idea that if a proper solution exists, there is no reason to recode the solution. The fine line lies with the word “proper”  though. Too many times, I’ve seen a complex solution to a problem be reused in many places it shouldn’t. Usually the solution gets a “band aid” so that it works within the scope of the new problem but this just evolves as more closely-related problems emerge and eventually the coder ends up with inefficient code that barely solves the problem. The world of development has  begun to rely on third-party libraries and frameworks and other people’s code so much that they sometimes have no original code in their project and there needs to be a happy medium between quality and speed of development. Sometimes it’s worth it to rewrite an entire procedure that isn’t quite getting the job done. Sometimes you have a completely unique problem that someone else just hasn’t encountered before.

I still go back the “don’t reinvent the wheel” idea. If you can use other code that’s available and satisfies the problem in an efficient manner, then it’s a good solution. We all need to realize, though, that wheels come in different sizes and shapes. You wouldn’t want to put a hamster wheel on your car, nor would you want tractor wheel in your amusement park instead of a Ferris wheel. In the end, code reuse is a blessing to developers. Being able to create rich software at a fraction of the time spent is a very powerful tool. The developer just needs to learn when it is appropriate to reuse code, and when they should develop a solution specific to their problem.