Your developer’s commitment to accountability will make or break the project.
Your vendor’s [lack of] accountability sets the stage for a successful software development project. Accountability requires open communication with your developer. It ensures an honest, realistic and goal-driven assessment of your project’s budget and schedule. That’s why accountability is one of our four pillars to project success.
Successful projects need two types of accountability: external and internal. External accountability involves good stewardship of your time and money. It also needs open communication from your developer on the status of your project. Internal accountability ensures your developer has created what you actually wanted. That means solid planning and application of that plan to their software architecture.
Hiring a developer who prioritizes accountability leaves you with a high-quality product. This guarantees timeliness and cost savings down the road.
Weekly updates keep the relationship professional and on task
Software developers should be transparent in their communication with you. illumisoft fosters transparency by providing weekly updates on the status of your project.
Dustin Ewan, vice president of software development at illumisoft, created this concept at a previous company with another developer.
Their company had a client who invested hundreds of millions into new technologies. Unfortunately, the relationship lacked accountability. They struggled to find a way to give the client peace of mind. Getting the product right was even more critical because emotions were running high.
“Once a company is in so deep with their vendor, it’s really hard to get out,” Ewan said. “If you have a relationship with a vendor who doesn’t hold themselves accountable, that relationship can turn sour, first of all. It can be painful; but not only that, you can just be stuck in a really bad situation.”
Ewan found that the only way to start bridging the gap was by providing weekly updates. Succinct, written communication had removed the emotion. It also allowed the client to focus on the state of the project.
The concept came from a bad experience, but the succinct format mended their relationship. And the best part for our clients? It helps prevent future relationships from going sour.
Weekly updates list priority objectives and any known risks
Our clients receive a super succinct weekly update from us. That update includes an executive summary of objectives we accomplished or made progress on.
The update also covers prioritized objectives for the coming week. That list is numbered so you can see what we’ve prioritized as the most important task. After reviewing the list, you’re also free to make adjustments yourself and tell us what you’d like us to focus on next.
Finally, the update includes any high or severe risks we’ve encountered. We only expose risks that are critical enough to raise to your attention when it’s 100 percent likely a high-consequence risk will occur
Let us sweat the small stuff; we only expose high risks to you
We identify, categorize and expose risks through a tool known as a Risk Matrix.
We categorize risks by severity of the consequences and likelihood the risk will occur. For example, if there is a 60 to 80 percent chance we will miss a hard deadline — and we’ve identified that missing the deadline is critical to project success — we will include it in the weekly update.
We only bring a risk to your attention if it crosses a high threshold. Examples include missing a deadline or exceeding the budget.
“There’s really no point in telling you every little thing that’s going on because then it’s just worrisome,” Ewan said.
You can also ask us to notify you of moderate risks, before they cross a high threshold. We will ask you about your risk appetite at the beginning of the project. That way, you’re exposed to whatever level of risk you need to feel comfortable.
When a high-consequence risk is 100 percent likely to occur, we will raise that flag and tell you immediately.
Good software development lies in a firm foundation
Your developer’s commitment to external accountability will be visible to you. Internal accountability, on the other hand, is more technical in nature.
“One thing a lot of people don’t really understand about programming is that there are infinite ways to accomplish a task,” Ewan said. “People imagine that: ‘Here’s where I am and here’s where I want to be, and there’s a straight line between them.’ It’s not like that at all in programming.”
Our founder, Dan Prince, likes to say that software development is art. Think about it. Someone tells you to paint a picture of a woman; just imagine how many variations of that you could get. There’s all sorts of things that you can do, and you could take it as deep or as shallow as you want.
But what if you had to hand your painting off to somebody else and then they had to work on it after you? Other artists have their own styles and may use different tools, such as charcoal or pastels. If you made it hyper-personalized, there’s no way another artist could add to that painting without the adjustments sticking out.
An architecture-first approach gets it right the first time
Another even better analogy is building a house. Whenever you decide to build a house, you always prepare a blueprint of it first. Imagine trying to build a house without a blueprint and instead build it organically. If you didn’t plan ahead, there’s very little room to make adjustments to the house without having to start all over.
Software development works the same way. In fact, illumisoft utilizes an architecture-first approach to our clients’ projects.
“By taking a look at how we organize our code upfront, we leave ourselves lots of room to expand,” Ewan said. “And we can make changes easily during the project because we have a solid architecture.”
First developed by Robert C. Martin (aka Uncle Bob), the Clean Architecture concept creates straightforward processes for software development. This allows project managers to scale up quickly by bringing in extra developers. New team members can then immediately identify the architecture and start working.
Without well-defined architecture, a team of, say, five developers could end up disjointed. They unwittingly add necessary complexity to the project. The more they code unguided, the more difficult it will be to merge the code produced by each developer.
“At first, things are going along pretty well and it seems like you’re making a lot of progress. But because you have five different developers all writing the code in their own way — without a shared common architecture or understanding of the architecture — it becomes more and more complex each time someone contributes to the code,” Ewan said.
Clean Architecture reduces overhead costs, saving you time and money
Sloppy projects tend to happen with developers who work for cheap. At first, you might think you’re getting a bargain and that you did the right thing by hiring the developer for $30 an hour. At first they are flying, but everything is going to grind to a halt because the project will become increasingly complex. As the complexity of the project increases, the developers have to spend more and more of their time communicating about how the code works and less and less time actually working on the project. This increases your project’s overhead costs, all because your vendor didn’t establish architecture of the project beforehand.
“They might be cheap, but how much of that money is just getting thrown away and wasted on overhead because they’re not holding themselves accountable to the quality of the product that they’re producing?” Ewan said.
It’s like the house analogy. If your developers don’t use the same tools and materials to build your house, you’ll still get a house. That house is going to look terrible and be unnecessarily expensive and dysfunctional. One guy might be working in brick, and another guy might be working in wood. When they meet up, they’ll have to figure out how they’re going to join the two materials together.
That’s why software architecture is vital to timely, cost-efficient project success. Vendors whose entire team understands the architecture can quickly and easily add developers. There’s no thought to how to organize the code; it’s already dictated in the architecture.
Hire a developer who reduces — and doesn’t accumulate — technical debt
Sorting through code that has not been well organized can also take a long time. One of our clients had a developer who worked for several years coding everything organically. We are still digging into his code and trying to figure out what he was thinking. There was no consistent thought process or organization from one idea to the next.
“There are so many traps and gotchas; it’s like the butterfly effect,” Ewan said. “Everything is so complex and interconnected that we don’t know where these butterfly effect type things are in the code. If we make a little change over here, it might have huge repercussions somewhere else because of how poorly or organically it was written.
“He wasn’t holding himself accountable to the code that he was writing.”
Our client is still paying off tons of technical debt because that developer lacked forethought. As a client, you often don’t know that you’re acquiring technical debt while it’s happening. But that’s exactly what happens when a vendor doesn’t hold themselves accountable. The vendor acquires technical debt for their client that the client will have to pay off later.
So, you can either pay to avoid the technical debt upfront — which is typically cheaper — by hiring a developer who considers software architecture from the beginning and holds themselves accountable to you through open communication… or you can pay off the technical debt later with who knows how much compound interest. Nobody knows how much time it will take to fix the project to make it more workable.
We recommend finding a vendor who understands the importance of avoiding technical debt.
Accountability to your project gives you a high-quality product
Accountability to you and your project all comes down to affect your bottom line.
But exactly what accountability looks like is often kind of difficult to describe. Of course, your developer must be a good steward of your time. Any time spent communicating about the project is time you have to pay for. You rely on your developer’s tech expertise. It all boils down to your vendor being a good steward of your money — whether you understand what they’re doing or not.
This is the part where you might feel leery or defensive of your developer. That’s why developing trust in the relationship with your vendor is also vital to project success. Weekly updates on your project are a great way to stay on the same page as your vendor. Your developer should communicate with you in ways that resonate with you. At the same time, your developer should focus on reducing project complexity. Simplicity reduces overhead time on problems that they should not need to discuss at all.
Ultimately, Clean Architecture offers a high-quality product that does what you wanted. It’s done in such a way that you can pass the project off to other developers as well.
Want to talk more about what accountability looks like for you? Let us know.