Which problems do you find in a software development contract?

Community Community & Industry Discussion
,
1

Hi everyone,

I’m currently writing a PhD about software (tailored made) development contracts.

As a lawyer, I’m trying to understand an engineer’s point of view in a contractual relationship, and particularly, what developers/engineers struggle with during a software development project. The aim of my research is to find the best solution in case of litigation or even to prevent such litigation from happening between the customers and the developers in a tailored made software contract. To understand the real experience of developers, I’ve a bunch of questions, and it would be really helpful to have your point of view and (possibly) examples from experiences you had in various projects:

  1. Which kind of process do you use for a software development project (for example, agile, cycle, waterfall, etc.)?

  2. How do you define a software’s failure?

  3. Which are the most common failures that you can find?

  4. How do you detect a failure?

  5. Which is the procedure to repair a failure that you usually use and why do you use this specific procedure?

  6. Which problems do you usually find in a software project regarding the client’s needs and communication?

  7. During a project, have you already experienced a problem that has rendered the software development (technically) impossible and/or extremely hard to develop (for instance due to the development taking too much time, or becoming too expensive)?

  8. How do you determine (or define) this impossibility or a piece of software that is “really hard” to develop?

  9. How do you usually solve this kind of issue?

  10. Do you have any other problems while developing software for a client (before, during or after the contract being concluded and/or performed, for example failed installation)?

Your answers will be extremely precious for my PhD thesis. Thanks a lot, in advance for your help and please feel free to also share these questions with your colleagues.

2

I think you may have unintentionally limited your research by making assumptions about the nature of the problems encountered in a typical SW contract.

I wonder if I could suggest a list / process, that I notice is much more common, maybe it is of some use.

  1. The employer looks for contractors to fulfil their development targets. Part of this, is giving a loose spec of what needs to be done.

  2. The programmer ( having been employed ), develops code to meet those needs.

  3. The employer then starts to move the goalposts around. This is partly due to not having a clear goal themselves, partly due to expressing their goal badly, but also, once run-able code appears, it actually helps them develop their ideas further. They have usually not factored this iteration cost into the project.

  4. The programmer then typically moves one of two ways:

a) Constantly re-writing code to fit the requirements, which shift further. A time-consuming process.

b) States that the employer is changing their requirements, which can, at worst, lead to deadlock, no payment etc.

Most contracts spend a lot of time on (4), and this can be resolved amicably. It really depends on how well organized things are.

2 Likes
3

Yeah, “sticker shock” and “desire to get something for nothing” are the most common problems for software development, when someone who isn’t a software engineer, or isn’t used to software development, tries to contract for something.

Walking on water, and meeting requirements, are both easy, if they’re frozen.

The problem is that a shockingly large part of what a software developer actually does, is not “writing code,” but “discovering hidden, assumed, and unknown requirements.” This is frequently a process with high uncertainty – much higher uncertainty than a construction project like “a bridge” or “a downtown office tower,” in fact. Complexity analysis shows that there are more moving parts in a typical software application, than a construction project, and humanity has been doing construction for 6000+ years, but software contracting only for like 60 years…

2 Likes
4

Thanks a lot @ClockworkOcean for your detailed answer!

So, in your opinion, SW contracts should focus more on the specification part, right? Maybe by giving some directives on how specifications shall be first defined? What do you think about it? Or do you have other propositions? They are more than welcome :slight_smile:

5

Thanks a lot @jwatte for sharing your thoughts! It’s really important to point out this complexity!

6

It’s true, clear specs can help a lot. This is why you have formalization of programming and project management.

But even given these tools, people still make a total mess of things.

At the end of the day, you can’t beat having people who are natural managers, project leaders and programmers. If you’ve got the wrong mix of people, nothing is really going to help.

1 Like
7

The problem with putting specifications in the contract is that developing the specifications is a large part of the effort!

Compare to construction – what most contract software developers do, is much more akin to what an architect does for a house, than what a carpenter does. Sure, there is also a bunch of carpentry that needs doing, but software development is less physical and can re-use more components than a typical building project, so, percentage wise, the time spent in requirements and specification development is much larger for software than for construction.

The process could really be split in three:

  1. Parameter definition – this is a high-level consulting engagement, figuring out what could be done at approximate cost and technology levels. Call this 2-10% of the work.
  2. Specification development – this is a time-and-expenses design engagement, where the actual definition of the product can be made and built, to the point where it’s possible for a buyer to say “I want this!” and for an implementer to say “I can build this!” Call this 30-70% of the work.
  3. Actual implementation – People push buttons to make computers do things, and out comes code you can run. While various interesting bugs will happen, and surprise technical limitations may occur, assuming pieces 1 and 2 were done right, the risk of error here is much less. Call this 20-68% of the work.

Now, back in the good-old-days when IBM sold you computer systems, they’d swallow #1 as business development, and they’d engage in a consulting project to do #2, and finally end up with #3, and once the real code was written, reality would mean that the customer frequently wouldn’t fully solve the problem they thought they were solving, but IBM doesn’t care – they just bill you as per contract. This might be a fine outcome for IBM, at the time, but not so much for the customer. This is the waterfall model, and legal contract frameworks exist to address each step of the way. It’s also a terrible match for modern software development.

Because many of the requirements are unknown and unknowable until you have something that works to poke at in reality, a much more cost effective way is to iterate through these three steps in some kind of circle or spiral. The idea of “agile” software development comes from this realization, and the idea of “prototype discovery” and (in games,) “vertical slice” all take root in trying to crack this nut.

A good engagement will then be structured as “let’s start small, do a simple thing, poke at it, and see where that goes, with potential contract extensions for any additional requirements discovered.” That model has, in general, worked much better overall for me. The main draw-back is that unsophisticated buyers don’t understand why it’s important, and don’t have the stomach for the significant uncertainty involved in even understanding where the finish line might be located, much less what it would take to get there.

8

I’m curious if anyone here buys or negotiates enterprise B2B software. If so:

  1. Is price a top concern when buying software?
  2. Do you negotiate contract prices? Why / why not?
  3. Who in your organization does the negotiating & purchasing?
  4. Would you be willing to share your pricing data in return for industry comparables to see if you’re paying a fair price?
9

Hi @AnderAI.phd This is a really much needed question asked for. I am Aliena Jose works at Techmango, software development company. I can answer you this.

When looking at software development contracts, there are a few key problems that must be considered to ensure all parties are protected throughout the engagement.

First and foremost, both parties should make sure to define the scope of the project with enough detail to know when it can be completed and any contractual obligations related to timelines or completion dates. Without such details, either party could end up in a situation where they have either overspent or taken longer than agreed upon for a job. Additionally, budget considerations should also be included in the contract so that everyone involved knows what is being paid for - otherwise there could be serious misunderstandings down the line about what work has been performed versus what was expected and/or contracted for.

Equally important is clear communication regarding ownership rights between each party. If intellectual property rights or copyright laws become involved then an agreement of who owns each aspect of the project should be outlined within the contract itself - this can save significant disputes (and costs) further down the road if one side tries to assert proprietary claims on materials developed by another.

Finally, how quality assurance will occur throughout different stages (as well as how disputes will get resolved) needs to also get defined within any software development contract - otherwise things like testing plans and requirements won’t necessarily get followed through on until much later when it may no longer even be possible under certain conditions/timelines due to other factors at play outside of just coding. And without clear dispute resolution processes both sides might find themselves at odds trying sort out issues after-the-fact which puts stress on developer/client relationships needlessly.