Leave a comment

Starting Your Development Effort Right

by Chris Durand, CTO

ChrisDurand-B360I 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!


Leave a comment

Even Agile Needs a Quality-First Focus

by John Brooks, Vice President of Engineering

john_brooks_b360_1There is no doubt that in the software development world, Agile Development is a hot topic. Just about every company engaged in software development describes itself as an “Agile house” and I haven’t seen a software-related resume without Agile listed in a very long time. Amazon Books has more than 2,000 books related to the topic.

This often leads to an automatic assumption in our industry that by practicing Agile methodology, the resulting software will be higher quality than it would be if another development methodology were used. Ubiquitous references to this exist almost everywhere Agile is discussed, and it’s easy to understand why. I believe there are very high value aspects to Agile practice that can benefit almost every project. But what we as an industry sometimes miss when we see one development practice as a miracle method is a focus on the real end goal of software development—quality—instead of how we develop it. We should be focused on delivering quality software that truly works as it should.

Too many companies and Agile practitioners take it for granted that high software quality is an automatic side effect of Agile; but just like any other methodology, Agile’s practices must be properly executed, or quality will suffer. Agile is great, but Agile alone does not a perfect project make. There are some ways to bolster your Agile practices for a tighter, more quality-focused development process overall.

Software veterans can tell you the Waterfall model with its “iron triangle” was almost universal back in the 1970’s and 80’s, and is still in practice in many companies today.[i] That iron triangle, consisting of requirements, cost, and schedule, created an unintended negative effect: the critical dimension of quality was not even included! With requirements, schedule, and cost all fixed, the only variable was quality. And we all know how well that worked out.

Steve McConnell, author of Code Complete and recognized authority on software development, recently addressed this during a speech in Austin that I attended. He has found, as I have, that what does work for most enterprise projects is a hybrid approach, and he’s done the research to prove it. Business leaders must be able to plan, budget, and determine business value at the beginning of a project. A pure Agile practice can make that difficult because the planning elements (of the iron triangle) are too vaguely defined at that point. By adding a bit of Waterfall up front, with Agile for the rest of the project, the business gets what it needs when it needs it, and development can utilize the more efficient Agile methodology. A Waterfall-Agile hybrid.

There still needs to be a focus on quality during all phases of the software development life cycle. The tendency to skimp on QA during a Waterfall project has transferred right over to the practice of Agile on many projects. Bad habits like code-and-throw, a lack of unit testing, long release to QA cycles, and not having testers involved early enough are symptoms of this.

The “extra room” created by the flexibility and speed of Agile should be used to more tightly integrate testing into the practice. Otherwise, the real world pressures of the iron triangle will still surface.

As an industry, we need to include predictability and quality as equals to the classic iron triangle elements of requirements, cost, and schedule. None of these elements should be considered immutably fixed. We can do this without throwing out the best of either Waterfall or Agile. At Bridge360, we specialize in the practice of delivering quality software first, no matter what methodology our clients are using. We help our clients implement lightweight, lean methods of delivering the best quality software possible.


[i] Leffingwell, Dean (2010-12-27). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise


Leave a comment

The ‘Ghost in the Machine’

by Jerry D. Cavin, Senior Software Engineer

Jerry_Cavin-3

Jerry Cavin is also an Adjunct Professor of Computer Science and Astronomy at Park University.

How many times have you coded an equation and the results produced are not what you expected? Then you rearrange the equation and get completely different results! If the computer is calculating correctly, why does it produce incorrect answers? Could it be the ‘Ghost in the Machine?’

Gilbert Ryle’s notion of the ‘Ghost in the Machine’ was introduced in his book, The Concept of Mind, a critique of Rene Descartes’ discussion of the relationship between the mind and the body (the mind-body dualism). The expression has been widely used in the context of a computer’s tendency to make unexplainable numerical errors. Are the errors the fault of the human, or is it the fault of the ‘Ghost in the Machine?’ To gain insight into these mathematical errors made by computers let us examine how the ‘mind’ of the computer views our concept of numbers.

INTEGER NUMBERS

The ‘mind’ of the computer perceives finite number sets. The size of the number set depends on the size of the space where the number is stored. If the number is stored in 8 bits, the number set starts with 0 and ends at 255. One of the bits can be reserved to represent the sign of the value (i.e. + or -). In this case, the numbers that exist are from -128 to 127. Numbers can also be stored in a larger space, but that does not change the fact the ‘mind’ of the computer still perceives finite number sets. So what happens when 1 is added to the maximum value in a finite integer set? It wraps around to the smallest negative value in the set. In our previous example for 8-bit values, when the computer adds 1 to 127 it would give the answer of -128. This overflow, or wrap around error, can occur if you are adding, subtracting, multiplying or dividing. Integer overflow errors are dangerous because they cannot be detected after it has happened. The ISO C99 standard states an integer overflow causes ‘Undefined Behavior.’ This allows compiler manufacturers, conforming to the standard, to implement anything from completely ignoring the overflow to causing the program to abort. Most compilers totally ignore the overflow, resulting in erroneous results being calculated. Depending upon how the integer variable is used, the overflow can cause a multitude of serious problems. If an overflow occurs with a loop index variable, it may cause an infinite loop. If an overflow occurs with a table index variable, the buffer overflow may cause data corruption. Another strange condition can arise with integers that we do not see in the human world. Under some circumstances an equation may give an answer of +0 or it may give an answer of -0. These two values of 0 are the same, but it may cause some confusion. This is a problem to many older compilers; some compilers detect this condition and simply change the answer to +0. Newer compilers use two’s complement mathematical operations and never encounter this issue.

What does your computer do?

Continue reading


Leave a comment

Requirements, really?

Nadine Parmelee

by Nadine Parmelee
Senior Quality Assurance Engineer

Change is hard. Project teams frequently resist the addition of new processes and procedures, and one process frequently fought is the creation and review of requirements. The reaction is understandable—it’s most likely resistance to creating more work in the midst of already tight schedules. On the other hand, some of the consequences of not having requirements or having poorly thought out requirements are:

  • Developers guessing how the application should behave
  • Secondhand guessing: testers guessing how the developers guessed the application should behave
  • Customers not liking or having difficulty with the product
  • Spending time and money reworking a product to remove ambiguities
  • Inability to map test case to requirements, which can lead to not really knowing if the testing is complete

The benefits of creating requirements and making them clear in the first place are numerous. Here are just a few:

  • Understanding the purpose of a new feature
  • Understanding the workflow of a new feature
  • Understanding the options of a new feature
  • Understanding how a new feature integrates with existing functionality

And that’s just the beginning of what ultimately amounts to a little time spent upfront for maximum gain and minimizing stress on a project.

Creating requirements does not have to be an exercise in torture. Even the most basic requirements list is better than no requirements at all. Whenever there is functionality without requirements, developers and testers will make assumptions on how each thinks the functionality should work. Those assumptions may not match the intended behavior. By at least starting a list with the most basic of the requirements, early misunderstandings of what is expected can be avoided.

Additionally, the more people that review the requirements as early as possible, the sooner questions about functional behavior and whether certain functionality is even possible can be raised and potentially save large amounts of time and money. Reworking requirements adds delays and costs to any project, so the better the requirements are to begin with, the more efficiently the project schedule and budget can be maintained. Reworking code over and over and the subsequent testing of that code can add even more costs and delays until the project team can agree on the desired functionality. The earlier everyone has the same understanding of what needs to be done and the desired outcomes, the more quickly a project can progress and the more quickly new personnel can get up to speed on what they need to do to help complete the project.

When requirements are organized well and are succinct and clear, it is easier for developers and testers both to meet those requirements and map specifications and test cases to those requirements and improve the product quality from the beginning. By having better quality early on, the odds of getting a project completed on time and on budget are greatly improved.


4 Comments

Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

by Phillip Smith

In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes.  Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.

Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem.  There is a balance between empowering the team and being so distant that you appear to be “checked out”.  Find that balance (it will vary by project and by team) and use it to your advantage.  Teams that work independently within a process set tend to accomplish a lot –  and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.

While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”.  In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.”  We can use that as an example of a situation that calls for specific action. Continue reading


1 Comment

Project Management Survival Guide Part II: Three Ways to Stay Clean While Doing the “Dirty Job” of IT Project Management

by Phillip Smith

Last week we talked about the dirty job of project management, and how the complexities involved in leading teams and implementing IT projects often make the PM’s job even messier than Mike Rowe on a sweeps week episode of Dirty Jobs.

Luckily for us, there are three tried and true guidelines for cleaning up even the messiest project—or even better, keeping it in check before things get out of hand. Here they are:

  1. Stabilize requirements and schedules
  2. Set up repeatable processes and tasks
  3. Allow team members to develop specialized skills that can be called on as needed.

1. Stabilize requirements and schedules

Stabilizing the requirements and the schedule is about managing the stakeholders.  It’s an art form that requires patience and understanding, and the good sense for compromise and protection of the project team.  If you lose too many battles here, the project may be successful, but you won’t have a team left to execute the next project.

2. Set up repeatable processes and tasks

Setting up repeatable processes and tasks is all about maturing the project team.  While every project is unique, the execution is not.  For example, there is always a design document.  Use the same template every time.  Use a reliable review process with team members who have the right knowledge.  Hold the design to a high quality standard, schedule enough time into the plan to do it right, and execute this way on every project so that all team members understand the expectation. Continue reading


3 Comments

Project Management Survival Guide Part I: Why Managing an IT Project is Different from Managing a Non-IT Project

by Phillip Smith

If you’ve ever watched an episode of Dirty Jobs then you’ve seen Mike Rowe get up close to some type of difficult and risky task. He usually reports on a sensationally dirty, greasy, goopy process that leaves him in need of a bath. While I suspect that he’ll never create an episode about IT project management, those of us in the industry know a dark secret: every day, we’re at risk of being slimed.

As IT project managers, we face risk and issues head on, often leading unproven project teams through difficult times to meet objectives set by a client with a limited timeline and budget.  We negotiate, we coach, and we deliver bad news.  We drive our teams like cattle and defend them like our firstborn.  We gather data that points to frightening conclusions, and then challenge ourselves to overcome.  We follow detailed processes and also make time for the soft stuff necessary to keep leadership, people, and clients synchronized. We’re surprised with ever-changing expectations, unforeseen expense, and impromptu meetings.  We travel, we sacrifice, and we deflect credit to the people that did the “real work”.

And when we tell our kids what we do for a living, they tilt their heads sideways and say something inspirational like “huh?”

At this point a sane person would ask, “Why do we do it?”  I’ll save that answer for a different article on a different day.  Instead, I’m going to explore some of the reasons this job is so demanding compared to other industries, and next week I’ll give you some suggestions for getting through its unique challenges. Continue reading

Morgan McCollough Bridge360


1 Comment

Is Silverlight Right for Your Development Team?

by Morgan McCullough

Before making the choice to use Silverlight or any other development tool, it is always important to examine the requirements and trade-offs.

Because Silverlight is a Web technology that allows the creation of rich Internet applications, it is positioned to offer many of the same benefits as a traditional Web application. The application can be centrally located and managed, and because it is accessible over the Web, can be used through corporate firewalls and does not require installation on client machines. Also, there is less need to move data around between disparate systems and a single interface can greatly simplify data access and security management. In general, Web applications are more manageable, highly deployable, easier to secure, and very often less expensive overall.

In light of all this, the question becomes what Silverlight offers above and beyond a traditional Web application that uses a combination of HTML, CSS, and JavaScript to create the client experience. In a business environment where Web applications have become commonplace, the capabilities of Silverlight must be compelling enough to make it worth the cost of time and resources. As with any new technology, the reality is that working with it effectively takes an investment for the development team to become familiar with its capabilities and pitfalls. An existing development team may be able to produce a traditional Web application with many of the same features as a Silverlight application in a shorter amount of time if you factor in time lost to research and study. Continue reading


Leave a comment

How to Maximize ROI When Re-Facing Legacy Systems

by Chris Durand

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


Leave a comment

Minimizing Risk in an Agile Approach

by Phillip Smith

The discussion about which project management approach to use is irrelevant if the chosen approach is not implemented correctly. The IT industry, while relatively young, does have reasonably well thought out software development processes (SDP’s) that are mature and reliable. Taking shortcuts within an SDP is never a good idea.

Whether using agile or waterfall, always make sure your plan includes stable requirements, optimized design, and rigorous testing. You should never tailor out critical deliverables, breeze conditionally through tollgates, or attempt to support truly impossible timelines.  It is better to execute in a reliable and true fashion and finish the project the right way, with quality. Stated another way, project managers should never use a difficult timeline or a low budget to justify chaos.

For example: in an agile approach, if you start with a very large scope and parse it into smaller components, and then execute all of the SDP phases for a single component prior to going in to the requirements for any other part of the scope, you will be running a great risk.  The lack of definition of follow-on components, combined with the finality of having the first component implemented, will certainly lead to integration issues and rework.

Continue reading