sourdough

Software and Sourdough

Written By: Steve Zagieboylo, Senior Architect at Calavista


My non-computer hobby since quarantine started has been making sourdough bread. I created my own starter and I’ve been making bread almost every weekend since last March. I’ve gotten pretty good at it, such that commercial bread now is unacceptable to anyone in my family. (In other words, I’m not allowed to stop making it every single weekend.)

In a Calavista company meeting last week I joked that I was planning a blog on making sourdough bread. The company president then challenged me to write a blog comparing software development to bread making. So here goes…

Software and Sourdough: StarterTeamSoftware and Sourdough: Plan

Software and Sourdough: ToolsI’d like to point out just how successful our processes are, both my bread making and our software development.  At 90+% on time and within budget, Calavista exceeds the industry norm by a ridiculous margin.  My success with bread is only around 80%; I’ve had a few bricks, but I’ve learned from each one.  (For instance, using whole grain flour means you need more water in the dough, and more time fermenting.)  Comparing the two processes was a bit of a stretch, but I hope it was entertaining and gave a little insight into the software development process we follow in Calavista.


Marten DB With Jeremy Miller

Written & Presented By: Jeremy Miller, Senior Architect at Calavista


The 6 Figure Developer is a website designed to help others reach their potential. They're focused on providing developers tools, tips, and techniques to increase your technical skills, communication skills, and income.

 

https://6figuredev.com/podcast/episode-181-marten-db-with-jeremy-d-miller/
https://content.blubrry.com/6figuredev/6_Figure_Developer-181-Jeremy_D_Miller.mp3

 

Marten DB with Jeremy Miller

 

In this podcast, our Senior Architect, Jeremy Miller, is interviewed by The 6 Figure Developer podcast hosts John Callaway, Clayton Hunt and Jon Ash. Jeremy has a technical conversation about Marten DB, a .NET Transactional Document DB and Event Store on PostgreSQL. Tune in to find out more!


irritant removal system

What Can The IRS Do For You?

Written By: Andy Fruhling, Chief Operating Officer at Calavista


As you start the new year and set your goals for 2021, I suggest looking into how the IRS can actually help youI’ve seen many cases where it has improved the user experience for key customers, built product capability beyond your team’s capacity and accomplished so much moreAs we are at the beginning of “tax season” in the United States, I should probably be a little more explicit.  I’m not talking about the Internal Revenue Service.  I don’t know anyone who has benefited from that IRS.  One of our customers recently called us their “Irritant Removal System” (IRS) and, after a brief chuckle, we saw how this concept  could be very beneficial to many companies. 

 

The Good, The Bad, and The Ugly

During my years of running product management teams at various software companies, I had my teams regularly conduct face-to-face meetings with our top customers.  The purpose of the meetings was to talk through “The Good”, “The Bad”, and “The Ugly”.  In other words, we wanted to hear directly from our top customers about what was working well with our product(s), what was not working so well, and what was driving the users crazy.   

I specifically organized the discussions in this order.  Hearing about what was working well (“The Good”), gave the product managers anecdotes we then shared with other customers and prospects.  We were also able to share “The Good” with the development teams, who too often only heard the negative and rarely heard about what was working well.   

Talking through what was not working well (“The Bad”) provided a good review of the top issues with the software for this customer.  Almost always the customer had already created trouble tickets for these items.  Further discussions during these meetings simply allowed us to get a better understanding of the issues including insight into the real “Why for these specific issues.  This provided a better view of the priorities for the top issues.   

 

The Golden Opportunity

For me, the real “Golden” opportunity was actually hearing about what was driving the end users crazy (“The Ugly”).  Initially, customers didn’t understand the difference between “The Bad” and “The Ugly” in this context.  The items that drive the end users crazy were irritants but not really bugs in the software.  Yes, they caused issues with the user’s experience, but they were not deemed worthy of a trouble ticket.  Many times, these items were relatively easy to address – perhaps something as simple as: “When I am doing this function on this screen, I need a couple of additional pieces of information from another screen.”    Sometimes they were more complex.  Either way, these items negatively impacted the experience of the end users and needed to be addressed.   

Although these customer discussions provided a lot of good information, they often did not lead to the results we wanted.  Once you have a list of irritants, what do you do with it?  The development capacity is usually fully committed to new features (roadmap) and bug fixes (maintenance).  Anyone who has actually run software development teams will probably tell you that these teams are always over committed on other items and the irritants had to wait unless you were willing to drop some roadmap items and/or maintenance items.  In other words, only a very small portion (if any) of the irritants were ever addressed and the end users see no relief from “The Ugly”. 

Eliminate "The Ugly" with IRS

Unfortunately, I did identify a good solution for this while running these product management teams early in my career or even as I, later, managed very large software development organizations.  It was always the same dilemma positioned around a tradeoff between the already planned roadmap and maintenance items versus the irritants.  Unfortunately, the irritants rarely made it to the list!  

It was not until our customer labeled Calavista as their Irritant Removal System that I made the connection.  As their IRS, we provide a cost-effective full team that delivers high quality code on schedule and can scale up or down as needed.  Let’s break that statement down.  Cost-effective means that our costs are roughly the same and perhaps even less than typical internal development teams.  Full team means the IRS includes more than just a couple of strong developers.  While strong development talent is a good start, you need the full team including management oversight, architecture, testing, DevOps, and possibly even automation of the development processes along with proven methodologyHigh quality code seems self-explanatory but too often this is overlooked, and people believe they can “test in quality” at the end.  We believe delivering high quality code requires a focus on quality across the entire software delivery cycle from initial story points through construction, testing, and production rollout with a consistent, repeatable, proven processes and DevOps automation where possible  We take great pride in our ability to successfully deliver projects “on schedule” for our customers at nearly 3x the industry average.  Like high quality, this comes from many aspects of our approach and has been proven on our projects for nearly 20 years.  Scale up and scale down provides the ability to address more irritants or less irritants as needed, based on business need.  With this model, the IRS can address issues that are impacting your end user’s experience with the software and help you address other items that do not fit within your internal development capacity.  So, ask yourself: “What can the IRS do for you?” 

 


code software development blue

Technical Debt Patterns: Copied and Pasted Code

Written By: Steve Zagieboylo, Senior Architect at Calavista


 

This is the sixth part in the series, "Technical Debt Patterns."

There are two (or more!) copies of the same bit of code, because some lazy (or unknowing) programmer copied a whole block and just edited a few of the lines.  Sure, it’s a lot easier than figuring out the right refactoring, and it gets the job done.

 

Why is it a problem?

I had another developer ask me that question in all seriousness, and I had to pause to answer without just referring to the obvious inelegance of it.  (He and I had debated before over the value of elegance; he didn’t think it was important.)  Fortunately, I knew of a specific example of his own code in which I had fixed a bug recently.  The bug was not an egregious error, just a weird situation not handled correctly, and was in my own code.

The problem was that after I fixed it, the bug didn’t go away!  I was so sure this was causing it, because it fit the symptoms so perfectly.  I finally figured out that actual bug I was trying to fix was in a parallel bit of code, the exact same error for the same reason, because the code where it was actually occurring had been copied and pasted from the place where I assumed it was happening.  In searching the code, I found yet another instance of the same problem, in a nearly identical stretch of code.  The other developer had copied and pasted the block I had originally written, and copied my bug.  It was fortunate that the copy I originally fixed hadn’t triggered the case I was focussed on, or I never would have realized that there were two more copies of the bug.

 

Cost Comparison

The cost of leaving these copies in place is clear, you can end up deploying code that has bugs in it which you have already found and believe you have fixed.  It is especially embarrassing when you inform your users that a particular bug has been fixed, and then have it show up again in a slightly different incarnation.  At the very least, the cost is that with every bug you fix, you have to double check whether or not that same bit of code appears elsewhere, and possibly make the same fix there, too.

The cost of fixing this particular issue used to be a lot higher, but with modern IDE’s and their powerful refactoring tools, it has become much easier.

 

How do I fix it?

The modern IDE’s have terrific refactoring tools to fix and to avoid this problem.  They will even point it out to you in many cases, though if there are enough small changes, they might miss it.  The refactor operation names are the same in both IntelliJ and Eclipse (for Java), as well as Rider (for C#).  I know that Visual Studio has the same refactor operations, but I’m not sure of the exact names.

  • Refactor / Extract Method
  • Refactor / Introduce Parameter or Refactor / Introduce Variable and Refactor / Inline Variable

First you extract the common bit of code as a method from one of the places where it appears, ignoring for the moment the bits that are different between the versions.  Consider whether or not this needs to be a static method, or if all the places that need to call it are in the same base class, and make sure you put it in that base class if this is the case.
In the new method, select a part that is different between the copies and use Refactor / Introduce Parameter.  The refactoring tool is clever enough to add the right value for the parameter in the calling code.

Another approach is to start by introducing a new variable for each of the different bits of code, move those above the code you extract as a method, and then inlining the values back into the method call.  (This is what we used to do before Refactor / Introduce Parameter worked so well.)

Finally, go to the other instances of the code and add a call to your new method, copying in the right parameters into the arguments before you wipe out the old code.

 

Your code has shrunken

If you’ve done the job right, you will have reduced the overall size of your code.  Of course, if anyone is measuring you by the amount of code you write, it is time to get a new job.

 


Continuous Deployment

Yes, Virginia, Continuous Deployment Does Have Controls and Approvals: Part 2

Written By: Daniel Kulvicki, Solutions Director at Calavista


In Part 1, we talked through some of the misconceptions of Continuous Deployment (CD) and how it does not create a “Wild West” release approach. This time, I want to cover three major flows or processes (using GitHub as an example) that can be implemented to enable delivery of stable, high-quality features while also allowing for code to be deployed continuously. Although most of the new code will have the new features turned off, we can still ensure minimal impact to the code in production. With this approach, releases can occur at a much faster rate as we are isolating areas to test while still allowing the code to propagate through all your different environments (Dev, Test, Prod, etc.).

 

1. Branching Flow

While there have been many branching approaches over the years, Calavista recommends a Trunk-Based strategy for Continuous Deployment. For Continuous Deployment, you need to minimize the time and effort of merging code
changes. This means your branching strategy cannot have multiple branches that require reconciliation as changes are merged together such as you see with development branching and release branching strategies. There is some expectation of automated testing coverage on every PR due to the fact we will rely on our automated tests to reduce overall manual testing time as noted in the PR Approval Flow section below.

As teams get bigger in size, sometimes short-lived feature branches will need to be introduced. However, they must remain short lived.

trunk based branching
                                           Figure 1: Trunk Based Branching

 2. PR Approval Flow

The PR Approval Flow ensures only high-quality code is merged into the Trunk branch. A Pull Request (or PR) is a
mechanism for a developer to notify team members that a unit of code is complete and ready for review before being merged into the code branch. Every PR that is created for Trunk will be required to go through a PR Approval Flow (such as the one below). While the approval flow may vary based on your specific needs, the flow must include the basics:

a. All PRs should create their own isolated environment for verification by people and/or automated tests

b. Each PR is tested to ensure the feature works as designed or bug fix is resolved as designed before it is merged into Trunk

PR Approval Flow
                      Figure 2: PR Approval Flow

3. Feature Activation Flow

Since features are usually deployed before they are activated, Product Managers will want a process by which to approve when a new feature is activated. New features have the potential to be turned off for extended periods of time before they are turned on. This can be due to Marketing Campaigns, Seasonal Patterns, etc. Below you will find the recommended Calavista Feature Activation Flow for Continuous Deployment.

Feature Activation Flow
                            Figure 3: Feature Activation Flow

While these approval flows provide a more substantial quality mechanism for Continuous Deployment environments, not all organizations are ready for CD. I have seen CD used effectively to create faster feedback cycles which in turn allow for a much faster feature development rate at lower costs and better overall quality. If you have teams that are not rapidly delivering high-quality code on regular, consistent basis, ask us how we can help.

In my final blog on Continuous Deployment, I will focus on Dark Releases (when features are turned off when deployed) and how to implement and maintain them for your organization.


Continuous Deployment

Yes, Virginia, Continuous Deployment Does Have Controls and Approvals: Part 1

Written By: Daniel Kulvicki, Solutions Director at Calavista


Often, Continuous Deployment is considered a step too far for most development organizations. Many people fear that it removes any gates or approval process and puts the release mechanism solely in the development team’s hands. This is incorrect. Continuous Deployment can actually can increase controls and provide better quality code!

I found an article online that described Continuous Deployment as too risky for any organization. Although the author made some great points, a wrong assumption was made that quality gates and even testers would go away. Yes, without quality gates and testers Continuous Deployment would be an absolute disaster. Continuous Deployment does not always mean Continuous Release. With concepts like A/B testing, feature toggling, and dark launches; it is possible to be able to continuously deploy safely, even to production, while being safe to your users. Below is a standard definition for Continuous Deployment.

“Continuous deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production.
To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code.

Instrumentation is needed to ensure that any suggestion of lowered quality results in aborting the deployment process, or rolling back the new features, and triggers human intervention.”

Per the definition, instrumentation and automation are very key principles to Continuous Deployment, however; I have found that there are other requirements for Continuous Deployment that are equally as important. Quality gates and work contained in small batches allow for the right mindset to perform more frequent releases to production. You want to build a cadence with your team without quality suffering. At Calavista, we have a good set of principles to help enable that speed of deployment with the right security blanket for your team.

In my opinion, Continuous Deployment will only become more popular in the future and adoption will increase greatly. However, we cannot just jump into it. It needs to be treated the same as an organization moving from Waterfall to Agile development. Many different parts of a company will need to change to adapt to the new release model.

In my next blog, I will address a recommended implementation of a continuous release chain that we support at Calavista.


shopping for quality

Shopping for Quality- How to Ensure You're Hiring a Company That Can Deliver

Written By: Lawrence Waugh, Founder at Calavista


I’ve written before that most people who are looking for a software development firm to deliver code for them tend to really care about 3 things. Those things are:

1) Price
2) Quality
3) Speed of delivery

There’s no surprise there – those are the things we all care a lot about in most purchases. No one wants to overpay, buy inferior goods, or wait interminably (or maybe indefinitely) for most anything they buy. I’ve written previously about ways to minimize cost (spoiler alert: Fixed Fee is not your friend). In this post, I want to focus on quality.

How can you be sure the company you engage will deliver high-quality code at whatever price you’re paying them?

The good news is that it’s easier to tell than you may think.

Don't believe the hype

The first thing to realize is that any company can say anything they want about themselves. It doesn’t matter how nice their website looks – that’s the work of the marketing group and has nothing to do with how well they actually write code. They can speak eloquently and say all the right things. That’s the talent of their salespeople. You may even speak to some of their engineers and think they’re brilliant – and maybe they are. But “brilliance” doesn’t necessarily translate into superior software delivery. Software projects fail over 70% of the time (according to the benchmark 2015 Standish Group Chaos Report) and very rarely do you hear that blamed on the poor quality of the developers. “Well, yes we were late, but what did you expect? All of our developers are below average in skill…,” said no development manager, ever.

There’s only one thing that matters when judging the likelihood of receiving a quality software product on time and on budget: the company’s history of delivering quality software on time and on budget.

Nothing that they say about themselves matter. The only thing that matters is what their past customers say about them. So, ask around.

There are references and then there are references

Well, that’s obvious - asking a prospective vendor for references is de rigueur. Typically, the company will provide 2, or maybe 3, customers for you to speak with. That seems right, right? I mean, how many calls do you really want to make?

It’s not enough. Not nearly.

Every company has 2 or 3 go-to customers that will say nice things about them. So, they get used a lot. Perhaps there are relationships involved that transcend work, or maybe they’ve just made those customers particularly happy. Regardless, even a small, new company can usually come up with a few people for you to talk to.

But think for a minute what that means.

Have they only had 2 customers? Or have they had dozens, but only made 2 of them happy enough to be a reference? In either case, is that someone you want to do business with?

A company that serves, say, 10 customers a year, and has been around for 5 years, will have had about 50 customers. Hopefully, a substantial fraction of those 50 would be happy with the work they did. So then why would they only offer you 2 people to talk to? Or 3? Or 5?

Ask them for 10. Or 12. Or 15. If they can’t provide you with that many, ask “Why not?” Have they not had 10 customers? Or have they not made 10 customers happy? It’s one or the other.

Regardless, if they can’t give you 10 or 15 references, ask them for a list of customers -- a complete list, not just a few. Then – after you have the list, not before – ask them for the name of the person they worked for at each of those customers. There had to be someone responsible for the project. If they say that the person is no longer with the company, that’s OK – get their name anyway. Then look those people up on LinkedIn, Facebook, Twitter, or whatever. Reach out to them and ask about their experience with the company.

You only need a few minutes of conversation to understand how the project went, how the company delivered. Most people will be happy to spend 5 minutes with you on the phone – whether their experience was good or bad. Don’t stop with one – call and talk to at least 5. In about an hour, you can talk to 10 of their customers. You’ll be surprised at the things you hear and then you’ll know the truth – or at least you will have an idea of the quality of work you should expect.

If delivering the project on schedule and on budget is important to you, is it worth an hour of conversations? It is the only way you’ll know the truth. Everything else is just hype.

Calavista claims that over the past 2 decades, we have completed over 100 projects, and delivered well over 90% of them on time and on budget. If that’s true, then there should be scores of customers who are happy with our work, and who should be glad to speak to a prospect.

There are. So, we lead with that. The first thing we’ll do when a prospect indicates serious interest is to give them a list of recent customers who will speak to them about us. To keep relevance, we typically limit that list to customers we’ve worked with in the past 3 years. That list typically has about 20 names on it from maybe 15 companies.

This just seems obvious to us. If you are looking at a company that will not (or cannot) provide this kind of list, you probably really need to understand why.

When you’re looking to spend a large sum of money on a software project, you need to do your homework. It may take a few hours – maybe even a day or two. But in the scheme of things, what’s the cost of that compared to the cost of a failed project?

And finally – once you’ve settled on a company to work with, and you complete the project (or don’t, God forbid) – be open to someone reaching out to you on LinkedIn. Be honest and objective. Because someone may be betting their career on your candor.


Software Projects

Software on a Budget- Charting the Least Expensive Path to a Successful Delivery

Written By: Lawrence Waugh, Founder at Calavista


I’ve a friend who’s a software architect for a large (Fortune-100ish) financial institution. If you ask him what his company’s priorities are when working on a software project, it’s simple. The number one priority is security. Scalability is a distant 2nd. Everything else is noise. If it’s going to cost $10 million to patch a potential vulnerability in their system, they spend it. If a scalability project will take 3 years, they go and do it. Money, time, and resources are just not their concern.

Must be nice. But it’s not the norm.

I’ve been with Calavista Software, delivering software projects to our customers, for nearly 2 decades. In that time, we’ve delivered well over a hundred projects for various companies. Beyond that, I’ve had conversations with hundreds more who’ve gone in other directions. I’ve come to develop a pretty clear picture of what’s at the forefront of a customer’s mind when they’re thinking about having a software project done for them. That’s pretty simple too. Generally, it’s

1) Price
2) Quality
3) Time to delivery

Each of these is worth a lengthy discussion, but in this post, I’m going to talk a little bit about price. Or pricing, anyway.

One of the first things that comes up in most prospect conversations is, “how do you price?” Generally in this business, there are 2 major pricing models: Fixed Fee and Time & Materials. The names are self-explanatory: with Fixed Fee, you agree upfront what you’re going to build and how much it will cost. There are acceptance criteria, warranties of workmanship, and service level agreements on how bugs will be addressed when they’re found. Since time to market is usually important, there may be penalties for late delivery. The idea is that you know what you’re going to get, when you’ll get it, and how much it will cost, so you can budget both time and money for it fairly easily. It’s a familiar and comfortable model, which everyone who’s ever paid someone to mow their lawn, or cut their hair, or build them a house, is familiar with.

Time and Materials is the opposite. With T&M, you pay for the effort, not for the results. If you have particularly unruly hair, maybe the haircut costs twice as much as the other guy’s. Or if it’s really hot, and the lawn care guy has to take more frequent breaks to avoid heatstroke, you pay for that extra time. If permitting is delayed, the house may cost another $10,000.

Given that, it might seem obvious that Fixed Fee is the way to go on a software project and a lot of customers come to Calavista looking for that. In general, we think that’s a huge mistake, and here’s why.

What's wrong with Fixed-Fee?

The advantages of Fixed-Fee are obvious. And if a builder can charge a flat fee to build your house, why shouldn’t a software company charge a flat fee to build your software?

In fact, at Calavista we often compare ourselves to a General Contractor building your house for you. Just as a General Contractor will bring together and manage the various skilled resources needed to build your house (such as carpenters, plumbers, electricians, stonemasons, and such), Calavista likewise provides and manages all of the skill resources required to build your software application (such as Software Architects, Development Directors, UI/UX Designers, Developers, Testers, DevOps Engineers, Requirements Managers, Business Analysts, and such).

So what’s the problem? The problem is, that unlike lawn care, or a haircut, software development projects change. A lot. Even building a house is generally a far more stable effort than building software. A house starts with a blueprint, which you’ve spent a lot of money on an architect to produce. The blueprints cover literally everything that will go into the house. Building materials, plumbing fixtures, where each light switch is, and how it’s wired. Very few software projects today start with that level of detail. Rather, most software projects today are developed using an Agile methodology¹, which embraces change. The truth is that even meticulously-planned software projects – which take months, or even years, to specify – will invariably change and evolve over the course of the development effort.

So, if a project is taken on as a Fixed-Fee project, that means that every time there’s a change to the original plan, the change needs to be evaluated, the scope needs to be adjusted, and the price for that adjustment needs to be agreed upon. On most software projects, this will mean innumerable delays, and inevitably, cost overruns relative to the original budget. In addition, it tends to put the customer and the software vendor into an antagonistic relationship. That is, the customer is always working to make sure that everything in the contract is delivered, on time and on budget – while the vendor is always motivated to make sure that they’re not adding anything at all that’s not in the plan, because finishing early saves them money, while finishing late is costly.

I usually summarize it to a prospect like this:

If you approach a builder who’s built houses in your neighborhood for the past 20 years, and say, “I’ve got a half-acre – I’d like a simple ranch home, maybe 3,500 square feet, a patio, and a standard pool out back…” – they will probably be able to give you a rough estimate on the spot. If you sit down and flesh it out a bit more, they can refine to something quite accurate. Because they’ve built a dozen of those houses in your neighborhood. They know the problems they’re likely to run into and how to get around them. So, their estimate will probably be pretty much on target.

If it turns out that you forgot to mention that you wanted marble floors throughout, they can still help you meet your budget. “OK, if those are important, we can do that – but we may need to lose the crystal chandeliers or maybe the hot tub. Let’s figure out what we can cut to make room in the budget…” If your contractor is good and trustworthy, they will work with you to get you the house you wanted, for the budget you’d agreed to.

It’s the same with software development. Calavista’s been doing this for so long that we can estimate most projects quickly, with high confidence of accuracy. If something unexpected happens, we work with the customer to figure out the best solution. Using this collaborative approach, we end up being on time, and on budget, about 95% of the time².

Contrast this to the customer who comes in with a 20-page specification and wants a Fixed-Fee price. We have to tell them:

  • The spec they’ve written is fine, but it needs to be replaced with a 200-page version. It’s not sufficient to say, “there will be a connection to a 3rd party payment gateway a customer can use to make payments.” Instead, we’ll need to know which one they want to use and what SLA they’re signing up for. We’ll need to evaluate the 3rd party’s API and maybe prototype it out so that we know for sure it’s going to work correctly – because we’re on the hook if it doesn’t. And we’ll need to have at least wireframes of the payment page to see its complexity. Maybe even some high-res art.
  • Then we’ll spend a long time scoping it out. We’ll go through each of the 200 pages in detail and figure out how much we’d expect to have to charge them to deliver that, and then we’ll need to multiply that by 1.x. Maybe 1.25, or even 1.5 – because now all of the risk is on us. If some piece of it is thornier than we’d realized, we’ll have to eat the extra cost.
  • Finally, we’ll end up fighting tooth and nail about what’s in the spec, and what’s a change order. The customer will want to get everything we’ve committed to for the fixed price, and we’ll want to make sure they’re paying extra for everything that’s not in the spec.
  • In the end, it’ll take much longer to start, will cost more (even without change orders), and we’ll be at each other’s throats the whole time.

It’s a horrible way to do business.

When Fixed-Fee makes sense

OK, there are some projects where it makes sense. In addition to the advantages to the customer listed above, Fixed-Fee allows a degree of flexibility on the part of the vendor as well. For instance, if we have extra development capacity, it might make sense to just put those spare resources on the project and finish early. If it’s T&M, I’d have to charge extra for those resources, but with Fixed-Fee, the customer gets the product faster, and I’ve increased my utilization rate for my people. Everyone wins.

So, for well-scoped, well-understood, and small projects – meaning they’re not big enough that they really can drift far – it can be simpler for everyone to just bid the price.

Caveat Emptor

Finally – this entire post has assumed you’re working with a reputable – and good – software company. If not, then T&M will just be a crapshoot. In that case, it might be better to invest in a detailed spec that you can live with and avoid changes. Or best yet, find a company that is good, and reputable.

How can you tell if a company’s good, and reputable? I’ll get to that when I talk about the “quality” priority in a later post…

Summary

About 90% of the time, Calavista engages customers in a Time and Materials model. This allows us to be less conservative with our estimates (i.e. lower the Total Cost of Labor) – not because the customer will pay for overruns, but because we and the customer both want to keep costs under control. On a Fixed Fee project, Calavista assumes all of the risks of unpredictable delays and must swallow any overage ourselves. So, we charge more. With Time and Materials, we can work with the customer to figure out the best way around an obstacle, rather than just paying to plow through it, so we don’t have to build those risks into the cost structure. For this reason, T&M estimates are generally 25-30% lower than fixed-fee bids, while still providing an excellent likelihood of success.

But again, finding a good, reputable company to work with is paramount. More on that later.


¹ en.wikipedia.org/wiki/Agile_software_development

² 94.4% at last tally


code software development blue

Technical Debt Patterns: Overburdened Class

Written By: Steve Zagieboylo, Senior Architect at Calavista


This is the fifth part in the series, "Technical Debt Patterns."

 

Some important central class has several not-really-related sets of responsibilities, making it huge.

Robert C. Martin coined the phrase Single-Responsibility Principle (SRP) as one of his core guidelines in object-oriented design. This states that “every module, class or function in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate.” This does not mean that every class should have only a single internal value, but that every class should have a single core purpose, one thematic element over which it is responsible.

Often you’ll start with the best of intentions, where you consider one class, perhaps an abstract base class, to encapsulate some significant concept which may be implemented in concrete subclasses. In the course of development, you realize that there is some functionality that is common to these base classes that might be unrelated, or only marginally related to the core theme of the class, but it is a convenient place to put the added functionality. Perhaps related to persistence of this set of classes, or a validation check (which seems related after all, it is the validation of the representation of the core theme). Over time, this secondary responsibility turns out to need a couple of functions, not just the one, and suddenly the class has several major responsibilities, seemingly grown from nowhere.

 

Symptom

One symptom that can lead you to consider this pattern is that a particular class file is getting a lot of merge conflicts. It seems that frequently several people are editing the same file, so there are frequently overlaps. An alternative symptom is that people have avoided this issue by clearly delineating, in comments, the code for one responsibility vs. the other (or others). This is a clear sign that your class has outgrown its purpose and is failing the SRP.

 

Cost

The cost to living with this transgression ranges from high (when there are lots of merge conflicts) to low (where the code is pretty stable and this core class sees very little action). However, it is rarely worth living with it, because the approaches to fix the problem are generally pretty easy.

 

Solution 1: Simple Separation Within the Structure

This approach is really just a formalization of the segmented code structure described as a symptom. You separate the class into two classes and an interface (or two classes and two interfaces, if you want to be even more pure). First, create an interface which represents the functionality you want to separate out. Your IDE should have easy tools to do this, where you just pick the methods to pull out. Second, separate the class into two classes, one extending the other, where one has only the methods and supporting properties for the interface, which should leave the other with only the methods and supporting properties for the other major responsibility of the class.

Now you can move to the clients of this class, areas of the code that are calling it. Hopefully, most of them only think of the class in one of its aspects, so you can change their reference to it either to be the interface or the new, cleaner class. This part of the exercise will possibly illuminate for you where the muddled thinking on the original class has led to some sloppy code. Or maybe it will point out to you that this over-burdening hasn’t really been costing you much, in terms of a clean architecture.

 

Solution 2: Delegation

Another approach to fixing this problem is to move one responsibility completely out of the class hierarchy into its own, completely independent class or hierarchy of classes. Then you make the original class delegate all that work to the new, referenced class. You still separate out the secondary theme into a new interface, but rather than this being just a sugar-coating over the fact that you’re still doing all the implementation in a single concrete class (having inherited some of it, but it’s all still there), you actually move the implementation into a completely separate class. Clients of this class now need to make a separate call to get to the delegate before calling whatever method they wanted to perform.

This approach makes a lot of sense when you realize that you would really like to abstract out some of this second theme of responsibilities, and maybe that becomes a hierarchy of classes all on its own, orthogonal to the hierarchy that the core theme represents.


Waterfall vs. Agile

Written By: Jeremy Miller, Senior Architect at Calavista


 

In Episode 401 of Software Engineering Radio, host Jeff Doolittle spoke with our Senior Software Architect, Jeremy Miller about his experiences with waterfall and agile software methodologies. Jeff and Jeremy spoke about the history of these methodologies, and what elements of them has been either detrimental or useful.  In their conversation, they also dive into topics like Extreme Programming, pair programming, self-contained teams, the emergence of Scrum and which practices can best be leveraged to help a team experience true agility.

Listen to the full interview in the video below. Or visit IEEE Software to read their summary excerpt.