Some new words and phrases I learnt

A few months ago I had a few chuckles over a LinkedIn article about Workplace cliche’s which landed in my inbox. So I figured I should touch base here and talk about some new terms that have come up into my vocabulary in the last few weeks.

We’ve been working with BBD on a project at work for the last few weeks, I’ve learnt a lot from the dudes, and a few new choice words to go along with.

Cookie Cutter

A cookie-cutter building or plan is exactly similar to many others of the same type (always before noun) The architects were determined that it wouldn’t be just another cookie-cutter mall. Management too often uses a cookie-cutter approach to solving problems.

This was the word that started it all. In one of the first meetings when discussing strategy and approach to the project, it was decided to ‘build a cookie cutter’ that would make subsequent cookies easy and quick to ‘cut’. Another word that was used in the place of a cookie was ‘slice’.

Cyclomatic Complexity

Cyclomatic complexity of a section of source code is the number of linearly independent paths within it. For instance, if the source code contained no control flow statements (conditionals or decision points), the complexity would be 1, since there would be only a single path through the code. If the code had one single-condition IF statement, there would be two paths through the code: one where the IF statement evaluates to TRUE and another one where it evaluates to FALSE, so the complexity would be 2.

This came up as a metric in code analysis. You never realise how difficult your code is to go through until you run a few metrices, baked right inside Visual Studio. I feel a little bad for sleeping on how rich VS actually is.

CI/CD – Continuous Integration, Continuous Deployment

Continuous integration is a strategy for how a developer can integrate code to the mainline continuously – as opposed to frequently.

Size is key here: smaller tasks (a day or less worth of work) mean daily code check in’s result in continuous integration, big tasks (longer than a day’s worth of work) mean frequent integration.

Continuous deployment means to always be able to put a code into production!

Fun fact I learnt at last year’s DevConf: Amazon deploys new software to production every 11.6 seconds. (via)

Blue/Green Deployment

Blue-green deployment is a release technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic.

There are plenty of ways to deploy a site to IIS, but this was new to me. How many times have you had a bugs that for some reason will only happen on a production environment? This allows you to deploy to production without taking production down, you can test your changes on production in a ‘blue’ version of the site while ‘green’ is active for your visitors and once you are happy you just redirect your site’s traffic to the blue instance and put green on passive mode.

The added benefit is that you can also warm up the new site before presenting it to your audience, which will result in an uninterrupted experience in your website, despite a deploy.

Technical Debt

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

A lot of the time in the haste of completing a project, one might take deliberate shortcuts in the interest of meeting deadlines. These shortcuts are the debt “the danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” So, a technical debt backlog/document is your little black book of debt to repay, in the form of proper re-writes.

Bonus: IoC and Dependency Injection

Inversion of control (IoC) is a design by interface strategy in which custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.

Dependency injection is a software design pattern that implements inversion of control for resolving dependencies. The client delegates the responsibility of providing its dependencies to external code (the injector).

These concepts I’d known about from a previous project as implemented by a colleague. But it was one of those it works, don’t touch it type of implementations. Only now do I realise how it actually works. This S/O answer explains it better than I would.

 

So yeah, most of these words were thrown out in general conversation. Makes you think we’re not all the same.

 

 

 

Write a Reply or Comment

Your email address will not be published.