One of the most important goals of a software engineer is to craft highly cohesive code. Cohesion refers to the grouping of code in a software system.
At Made we host regular client showcases, this is an opportunity to sit down with the client to discuss how the iteration and the project as a whole are progressing.
As developers we always appreciate a second pair of eyes and an extra brain. The eyes are really helpful for catching that extra whitespace you might have missed. The additional brain power might help you solve a problem in your code with 5 fewer lines. All of this results in better code and more collaboration.
When we run a test suite in most languages, we can also generate reports with percentage of code coverage. These reports aren’t all they are cracked up to be.
Note: Article edited on the 4/12/2018
Often customers, or potential customers, will come to us with a pre-supposed view that they need to build a piece of software to solve their business need. We believe this is true only in a handful of cases.
As an industry of tinkerers, optimisers and perfectionists we occasionally miss the beauty of unorganisation and human instinct. Our obsession to be more efficient and productive can sometimes have some undesired consequences. At Made we often adapt our processes in the name of efficiency but lately we’ve started experimenting by taking away some of these processes with surprising results.
Traditionally, software is delivered as a project: a thing with a start and an end date, and probably a list of desired features. The software is (hopefully!) deemed complete by the end date, the project is closed, and the project team move on to their next project.
Over the past year I’ve worked on a number of projects that have involved some large organisations. By large organisations, I mean, big hefty things that have been around for a while, have lots of cogs and yet still achieve a lot.
I spoke last time about the organisational challenges of adopting Continuous Delivery. One of the key takeaways was the importance of blurring the boundaries between team ownership in order to facilitate better adoption. This time around I want to zoom in a bit and focus specifically on the challenges faced by specific parts of the pipeline. Depending on how far through adoption you are, you likely no longer have dedicated teams for each of these functions, though the problems outlined here can still exist and derail even the most cross functional of teams.