I'm in the early stages of learning design-by-contract (DbC). And I think that if followed correctly, it can produce very high quality software. This gets me wondering though... why isn't it used a lot? Are there some issues in using it effectively within the typical software development process? For instance, does it make changing the requirements midway of a project difficult?

I know that for some problems, it's difficult to express the solution using DbC. But I think if practiced properly, it can save teams from maintenance head aches. And considering how much resources are expended on software maintenance, the upfront cost of using DbC during design time may be well worth it.

  • Design by Contract is just like anything else; the benefits need to exceed the costs. For some software development teams, it's worth it; for others, it isn't. Dec 16, 2016 at 3:58
  • So it's just all about people? I'm asking because if that's the case... can you see any potential technical problems in the aspect of software development if I include DbC into the parameters I use in choosing partners and first employees for our startup? i.e. Can I craft the direction of my future team's culture to start with DbC when designing the software component of our product much in the same way that I can inject a culture of innovation from the get-go? Dec 16, 2016 at 4:10
  • 1
    You're the boss. The head honcho. Mr. Big. El Numero Uno. Jaws. So you can tell team to use DbC. Especially if you can pay them real money to work on your project. Dec 16, 2016 at 5:17
  • 1
    I don't want to be a boss. I want to lead. I suppose that's the point of the question. I don't want to direct our startup to failure. So I'm going to people more experienced than I am to warn me of any possible pitfalls of the road I'm trying to carve. Dec 16, 2016 at 5:27
  • 2
    Maybe this question covers what you want to know: softwareengineering.stackexchange.com/questions/128717/…
    – Doc Brown
    Dec 16, 2016 at 9:09


Browse other questions tagged or ask your own question.