Tag Archives: Chris Durand

Want a guaranteed way to reduce your spend on software development? Do less. Really. Testing too expensive? Test less! Development too expensive? Develop less! Does this sound too good to be true? The good news is that most teams can benefit tremendously from this approach. The trick is to identify what to do less of.

Are you looking for new way to solve pressing technical problems? Well, I’ve found one, and I recommend it for anyone looking for a fast way to start a problem-solving process. I call it the “straw man” technique, and it’s pretty straightforward:

Think of the simplest possible solution or partial solution for a problem. This is the “straw man.”

Discuss with your team reasons why you think the solution will work or not. My favorite question to ask is, “Why won’t this work?”

Modify the straw man accordingly and repeat until you have a useful solution.

That’s it! I find myself using the straw man technique often; you can, too. Imagine you and your team are looking for answers on how to solve a challenging problem or implement what appears to be a complex feature. Think of a super simple solution that addresses at least 50-60% of the problem and ask the team why it won’t work. Then iterate from there until you reveal an acceptable solution. Continue reading →

Let’s be honest, Quality Assurance is a necessary evil. Many of you have probably wondered why developers can’t just get it right the first time. Why do we pay developers to write bugs, and then pay testers to go and find them?

The answer simply stated is — writing software is hard. Software developers need to be extremely detail oriented, yet also keep the big picture in mind. They must balance short-term tradeoffs with long-term considerations. They often have to learn new tools and technologies with each project while balancing the demands of outside influencers. Oh, you needed that feature or bug fix done yesterday? And you want that application to work on all browsers released in the last 3 years (that’s 24 versions of Google Chrome alone since March 2011), plus mobile? It’s no wonder developers struggle to write perfect code every time.

While it can produce quality results, the old model of throwing code over the wall from the development team to the QA team is inefficient. We that build software have to do more for less, faster, and in a more complex environment than ever before. The rise of automated unit testing and Test- or Behavior-Driven Development (TDD and BDD) is an attempt to realize improvements. By testing at the core (that is, with the developer), we find bugs as early as possible (which yields tremendous savings as discussed in the post https://bridge360blog.com/2013/12/04/5-ways-qa-supports-development/). Automated unit testing also makes it easier to update the application going forward by identifying unexpected broken dependencies in the code before they get in front of a customer. Continue reading →

Are you thinking Development and Quality Assurance are separate, independent activities? Think again. Development and QA go hand in hand, and the better (and earlier) both teams are engaged in solid quality processes, the stronger your software will be. Here are five ways software quality supports your development team.

1. Software Quality Reduces the Cost of Fixing Bugs

At the risk of beating a dead horse, if you are not familiar with the cost of fixing a bug at various stages in the software lifecycle, this graph is crucial:

As you can see, the later in the development cycle a bug is discovered, the more it costs to fix. If you find a problem in the requirements analysis phase, you simply change the requirements document to fix it. If you don’t discover that same issue until you are testing your beta release, you have to change the requirements document and rewrite code and retest. A good QA process will find defects earlier in the development process and reduce the cost of fixing those defects.

2. Software Quality Improves Requirements

Doing requirements well is hard without a strong software quality process in place. In many projects, testing begins too late since testers don’t start writing test cases until they have (hopefully) working code in their hands to break. If this is your process, you are missing out on the benefits of having the QA team engaged early on in the process. Strong QA professionals have an eye for detail and ensure your requirements are clear and testable. If your QA team cannot start writing test cases based on requirements, it is likely you have insufficient detail in your requirements documentation. This means you are leaving it up to a developer to self-determine many details of how your application should work instead of building a customer-driven application. So if your QA team says they cannot start writing test cases until they have a working application to reference, get them involved early and shore up those requirements.

3. Software Quality Improves Predictability of Releases

Predicting time to completion is challenging on poor quality projects with loose processes and parameters. Again, testing early is key. Feature development has a finite list of things to do, but the number of bugs in an application is unknown until you start testing. A strong QA process tests early and often, so at all stages in the development process you have an idea of where you stand. A weak QA process tests too late or not very thoroughly, and you find your dates slipping because you are still finding more and more bugs with no end in sight. High quality software also has fewer customer support issues and therefore your team can stay focused on new features instead of getting randomly pulled off to deal with the latest customer crisis and torpedoing your release schedule.

4. Software Quality Allows You to Refactor with Confidence

Writing software is a lot like gardening. Old plants must be removed, new plants added, existing plants trimmed and dead growth removed. Failing to keep your software well-groomed results in buggy software that is difficult to understand and expensive to maintain. You find you can’t easily add a simple feature because it breaks something elsewhere. To avoid this you must constantly keep your software pruned, and restructure parts that no longer make sense. Strong software quality allows you to do this with confidence since you know how the software was supposed to work before you made changes, and you can verify the software still works after your changes. If you have an automated unit or functional test infrastructure in place, that’s even better.

5. Software Quality Improves Team Morale

No one likes working on projects that have a bad reputation within the company or with customers. High quality software improves the morale of everyone from the sales team to the support team. The sales team has confidence that the product won’t blow up in their faces during a demo and that they won’t be damaging future sales opportunities by selling the customer a “lemon”. Developers feel more pride in their work and perform better since they want to maintain the good reputation for the project or team. The support team does not dread yet another call from an upset customer due to issues that clearly should have been caught during the development process.

In summary, if you don’t have strong quality practices in place, your development team (and the rest of the company) is missing out! Get your QA team involved early and often in your development process and watch your development costs shrink, schedules become shorter and more predictable, and customer satisfaction soar. Happy testing!

I recently had a discussion with a friend who owns a small business and needs a web application to run day-to-day operations. She’s a pretty savvy person but has a limited technology background. She came to us looking mostly for help in laying out the requirements, and how to hire a contract developer. But software can be a complicated business with thousands of little questions and details lurking around every corner, so we wanted to give her some advice to help her avoid the pitfalls. Here were the key takeaways.

Define the Scope

First, be clear about the scope and what you are trying to accomplish. For many projects, a phased approach is best, especially for smaller companies with more limited resources. Trying to do everything in a single release costs too much and takes too long, which drives up the risk. If you have finite time and resources (and most of us do), every addition to scope is a potential subtraction to quality control and keeping to your delivery schedule. You are better off determining what you absolutely need to get out the door in phase 1, letting it generate revenue while you plan for your next release. Be ruthless about cutting features. Often what you leave out is just as important as what you put in.

Screen Mockups

Once you have an idea of what you are building, you should make screen mockups to clarify which screens you need in your application and what is on them. You can include brief notes with the mockups to point out key details or functionality that is not obvious. You should have at least one mockup per screen in your application. Screens that have different modes or layouts may need multiple mockups to fully illustrate what is going on.

I like to start out sketching on paper; then once I have a rough idea of the layouts and content, I use a mockup tool to do more comprehensive mockups. My favorite tool for this is Balsamiq (http://www.balsamiq.com/). It’s cheap, easy to use, and gives great results. The key here is to focus on layout, content, and function, not colors, graphics, and making things look pretty.

User Stories or Workflows

Now that you know what screens you need, it’s time to write up workflows (sometimes called user stories) to explain how key features will work in the application. You know that hand-waving you’ve been doing about how customers will find a product, add it to their cart, and check out? Now is the time to get down to specifics: which page are users on at each step? Which button is the user clicking on each page? Simple workflows can be done in a bulleted list, while more complex workflows may require a flowchart or other diagram. This helps you understand how your screens work together, and the application as a whole.

Requirements

Mockups and workflows fall into the general category of requirements, but here I’m talking about other details that are not easily captured in these earlier efforts. If you want your application to do something specific, you need to write it down. The more detail you can provide, the better you understand your application and the more likely you will get what you expect from your development team. Here you can list out details for each screen like how to handle errors, how many characters each text field should hold, and anything else that you can think of that is important.

Summary

Software applications contain thousands of details. What color should something be? What happens when a user clicks this button? How long should a product name be? (30 characters long? 100 characters long?) Developers have to make dozens of decisions about these kinds of things every day. If you don’t make these decisions up front, your developer will make them for you, and they may not always do what you want. Good developers know what details matter and require additional input from you without bothering you with trivial issues, but they are not psychic. The more you clearly understand your application and can convey it to the development team, the more likely you will get what you expect and have a successful development project. Good luck!

Machine translation is the use of software to translate text from one language to another, usually without assistance from a human translator. It is a fascinating field that is changing rapidly, but here’s my take on where things stand today.

The Good

Machine translation is cheap, and it is getting better every day. I was encouraged by the success of IBM’s Jeopardy-playing system Watson in drubbing its human challengers. Watson’s ability to “understand” idioms and natural language will contribute greatly to the future of machine translation.

Translation projects vary in requirements for accuracy as shown in the following diagram. For projects jobs where accuracy is less important, machine translation is a workable alternative. An example of this would be a company support forum, with huge amounts of user-supplied content. It is not cost-effective to pay a human translator to translate every post by a user into numerous languages. However, a machine translation engine that has been tuned to translate support issues for a particular product won’t create perfect results, but may still be a valuable resource to users. And creating value is what translation is all about.

Of course there are many translation jobs where accuracy is critical, such as legal documents. And translations of literature, poetry, and the like will remain difficult for machine translation software for years since there is much more to this sort of translation than accuracy, such as style and other artistic considerations.

But with continuing advances in computing and linguistics, the line shown in the above diagram will move steadily to the right over time. Continue reading →

Over the last few years we have completed a number of “legacy modernization” projects wherein we build a browser-based user-interface for iSeries (AS/400) and 3270-based applications while keeping the business logic in the host application (“re-facing”). Here are a few things we’ve learned:

Re-facing without Extension is a Waste

The main reason a browser-based interface to an application is useful is because everyone knows how to use a web browser. If all you are doing in your web interface is converting function keys to clickable links and adding eye-candy, you will struggle to find enough ROI to make it worthwhile. If you are trying to eliminate costs associated with deploying green screen emulator software to user desktops, you are better off deploying a web-based emulator product instead of beginning a screen re-facing development project. Continue reading →