Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.

Crappy Code Judgement

Derek Comartin 1 Comment

What’s the first thing most developers say after diving into legacy code?

It’s crap.  Giant plate of spaghetti!  What in the world was the person who wrote this thinking?

What’s interesting is we ask this question without really trying to answer it.  What were the objective and/or constraints to the person who wrote it? Without knowing this, you are making your judgement on unknowns.

Example #1: You have 30 days to complete.  This application is only assumed to be a temporary application.

Example #2: You have 30 days to complete, but don’t spend more than 16 hours.  This will be a legacy application.

Time and legacy are important objectives/constraints that were given to example #1.  Why practice programming to interfaces and create abstraction if you are writing throw away code?  If you know you are writing legacy code, maintainability is going to be more important.

We also often fail to acknowledge the technologies and practices that have changed.  Look back at your own code from 6 months to a year ago.  Do you catch yourself thinking:

I could of written this better by applying “X” pattern or following “X” principle?

Don’t be so quick to judge at first glance, unless you know all the objectives.

Continuous Integration vs Continuous Delivery vs Continuous Deployment

Derek Comartin Leave a comment

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.