Category: Practices

Continuous Integration is a term/buzzword that seems to have a clear understanding.  Continuous Delivery and Continuous Deployment on the other hand, seem to get incorrectly interchanged.

Continuous Integration

Continuously integrate changes into source control in order to test changes through automated builds and unit tests.  This provides developers with early warnings of broken code/merges and allows them to fix problems continuously.

Continuous Delivery

Some have the opinion that continuous delivery is when you deliver to a user base, such as UAT or QA.  I personally disagree.  Continuous delivery is about making sure your software is always production ready.

via Jez Humble (The guy who wrote the book… literally)

In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production.

There could be situations or reasons why you might not want or cannot deploy every good build to production.  However the idea is that every build could be released to production.

This implies continuous integration and higher level of automated testing.  It also allows Dev Ops and others outside of the development life cycle the ability to determine when to deploy to production.

Continuous Deployment

This takes continuous delivery one step further by automating deployment to a production environment.  This implies continuous integration and continuous delivery.

Fixed price, fixed scope development contracts are still a very relevant and are not likely going away.  Clients want a to know how much they are going to spend and exactly what they are going to get.  The reality is, iterative development was created because they don’t know (entirely) what they want up front.

Waterfall is still primarily used, however the reality is, it’s more of a business decision than a development decision.

Same old story…

We spend a great deal of time up front gathering business requirements and attempt to create a specification of our interpretations of those requirements.  We then learn new requirements which result in change requests.  Changes are generally viewed negatively during waterfall, even though they are getting the customer closer to the solution they want.

During implementation, there should be no business logic decisions to be made by the developers, right?  We should of defined all of this in our specification.  Ya right.

After implementation, testing, and delivery, our customers get their working software.   What is their reaction?

This isn’t working they way we wanted.

And then our response:

Yes it is.  Look at the specification.

This turns into meeting after meeting with no one happy.

Reality

The idea is that a waterfall project with a fixed price and fixed scope will let the client know exactly how much it is going to cost, and exactly what they are going to get.  The reality is they will get exactly what we documented from our interpretations of their requirements.

We document all scope up front so we can be certain that everything needed will be in the system.  Reality is the client cannot visualize everything they need in the system and requirements are missed and are moved into change management if they are ever realized.

Fixed price contracts are viewed to favor the client. The reality is they should favor the vendor who can handle change management correctly.  Other fixed priced custom solution industries (mold manufacturing) make their money not on the initial proposal, but in change management.

The reality is that there are constraints that force us into a fixed price waterfall process.  Project management, client expectations, and client education seem to be the key to success.