The Discovery – Refactoring Software Development

Refactoring Software Development

I have been writing code for as long as I can remember. I have done everything from working as a developer, a consultant, an architect, to being a development manager and ultimately becoming an executive running large scale technology organizations. As such, I have had the opportunity to work on many different types of software teams across many different types of organizations. Throughout my career I have often encountered many inefficiencies in how software is developed. This is especially obvious when software development agencies develop applications for corporate or enterprise clients. I have heard more than one manager voice the notion that software projects with vendors always “cost twice as much and take twice as long” as advertised by the vendor.

When we started Pythagoras, we knew from our inception that we didn’t want to be just another software development agency…we wanted inspire change in how software is developed. We wanted to create a better way to deliver software that is on time, on budget and most importantly keeps the customer happy. We wanted to defy the stereotypes that persisted about software development agencies and show that there is a better way.

This series will explore the topic of the software development process and our approach to refactoring that process for the better.

“How much will this cost me?”

Pricing software consulting service is usually thought of as a very simple equation; developers bill hours against a particular project and the agency bills the client for those same hours, albeit at a higher rate than they are paying the developers. Everyone makes money and everyone wins…right? More often than not in this case the customer is the loser. Projects that work under a “time and material” model are really setup to take longer as there is no incentive on the part of the development agency to hit agreed upon milestones. Often times good faith estimates are given to the client, but these are only good faith estimates. If a customer needs their application by a certain date and the application has fallen behind schedule, then that client is more likely to continue to pay more and more developers hours in hope of getting the project back on track. What is the alternative?

When we approach a project at Pythagoras, we tell the client exactly how long it will take us and exactly how much money it is going to cost. This type of “fixed cost” pricing has many advantages for the customer. The customer can set aside an accurate budget with confidence that the delivery targets are going to be met. This sounds too good to be true. How can any software development agency be so brash as to tell the customer that they know with confidence what it will take for a project to be delivered? There are too many unknowns you might say. There are so many things that we will discover along the way you might argue. I would say you are absolutely right on both counts. So why not discover what we don’t know before we start!

The Discovery

We like to start every engagement at Pythagoras with a discovery phase. The discovery phase is a way for us to gather as much high level information as we need to properly scope out the work involved in a project. This in turn allows us to make a much more accurate assessment of the level of effort needed to deliver the project. Think of the discovery phase as the sprint zero of your project. Not only are we gathering information on how to architect and develop the application, we are also building out ground floor components.

The discovery phase can be anywhere from a few days to a few weeks, depending on the nature of the project and the size of the organization. We like to have our team onsite with the customer during the discovery phase so that we can integrate with the team and truly understand the business as well as the technical landscape. We meet with key stakeholders from both the business and the technology teams and hold workshops. We deep dive into not only the technical architecture of the application, but also the larger enterprise ecosystem. Everything from source control to continuous integration play factors in estimating the level of effort. We produce tangible assets at the end of the discovery phase that the customer can use as a play book. Everything from wireframes and mockups, to technical architecture documentation and sometimes even a proof of concept. We produce a full backlog of user stories and development estimates. We give high level timelines and milestones that we can confidently say we will hit. We even put together a full project plan and hand these assets off to the customer. We feel so confident in fact about our assessment that we often tell the customer that should they so choose they could take the deliverables from the discovery and have other firms bid on the project.

The discovery phase is:

  • Deep level of understanding of requirements
  • High level technical architecture
  • Comprehensive user story backlog
  • Creative assets (wireframes, high fidelity mockups)
  • Accurate assessment of level of effort
  • Accurate timelines
  • Fixed cost that will not run over your budget

The discovery phase is NOT:

  • Requirements gathering session
  • Development
  • High level estimate
  • Open ended engagement with no deliverables

Discovery Adds Value

While there are so many obvious advantages to conducting a discovery phase, it can sometimes be a difficult sell. The discovery phase is not free. There is pushback at times from the customer about spending money on a project before development even begins. The key though is that a discovery phase adds value, plain and simple. In many ways, the discovery is in fact the ground floor work for the development project or the “sprint zero” of the project. Spending a little bit of time and money up front to ensure that the project is properly laid out will not only yield a better product, it will actually save money at the end of the day!

In conclusion I would like to leave you with a simple analogy. If you are going to build a high rise tower, you don’t just start piling bricks on top of one another. Take the time to plan, architect and engineer the most efficient way to build a strong and long lasting structure before you lay down that first cornerstone.