Pro Tips for a Successful Software Project


We see a myriad of technology projects ranging from small internal apps and ambitious startup endeavors to enterprise mission critical software. Here are a few practices we use to deliver high quality software on time and on budget. These principles have proven invaluable when working with our clients and will enable you to avoid common pitfalls. We catalog them here to give our potential clients a feel for how we work together.

Don’t underestimate software complexity

Everyone is guilty of underestimating complexity. Consideration of complexity directly impacts product quality. Neglecting complexity is often heard of as focusing on the “happy path”. Let’s take a real world example:

“Send the user an email when they register.”

This is not a contrived example. Complexity grows as the number of devices, screen resolutions, browsers, operating systems, users, products, tax rules, state regulations, payment methods, and business exceptions increase for your software. Computers don’t have common sense to handle complexity. Complexity must be considered and addressed.

The development team only develops for the happy path if the business fails to consider alternate cases. Good development managers can identify the red flags for “happy path” language used by product owners:

“I just need”
“All I want is”
“It’s simple, just”
“It should be really easy”

Product quality, defects counts, customer satisfaction, and revenue all suffer from inattention to complexity. This results in inexplicable errors and odd behavior which confuses and frustrates users and business operations. As the pressures mount, the need to handle these missed requirements gets pushed into poorly thought out and executed quick fixes. These rarely have the desired short-term effects and usually result in long term negative impacts on mutable software and business growth.

Demo on day one

On day 1 there should be a demo. Before requirements are solidified everyone should have the same understanding of what the baseline technology offers. Every project has some previous foundation on which it builds. It could be a UI framework, a 3rd party solution, or some other library.

It is critical for the project owner have a solid understanding of baseline functionality. We want to avoid budget or timeline surprises because an assumption was made based on lack of knowledge. It is much easier to handle any gaps in understanding or expectations regarding the requirements of the end product when the product owner can experience baseline technology as it will be used. This allows the team to build an accurate backlog of features needed to complete the business objective.

Eat the frog

I’m positive Mark Twain wasn’t a software developer. However, he does have a gastrointestinal suggestion for doing the difficult things first, which is great advice for developers.

“Eat a live frog first thing in the morning and nothing worse will happen to you the rest of the day.” – Mark Twain

Every project is a mix of work that the team has done repeatedly combined with some new challenges. These challenges come in the form of new technologies, business processes, and 3rd party services. These new challenges are also the riskiest area of any project.

Taking on these risky areas of the project first can mean the difference between success and failure. Adjustments can be made if a problem is identified early. As Barrett Simms, our Lead Solution Architect, likes to say “Bad news early isn’t really bad news”.

Everyone is a tester

In many projects, the testing effort begins when the development is complete. This is already too late. Testing by the product owners (see above) needs to happen during development and frequently. This allows continual feedback of defects and feature behavior. Early feedback to the development team results in the business receiving the envisioned product.

Developers must have their own testing processes in place, usually unit testing. This is not something which needs to be approved by the business. This is part of good software development practice. A good lead developer or architect should set up and enforce this practice for the team.