Thoughts from a Thirsty Bear

Back in 2009, a fine developer for Los Techies produced a set of mocked up motivational posters representing the SOLID principles . She was even kind enough to release them under a Creative Commons license. But as is the way of all things, internet rust has set in and the images have been unlinked from the original article during an archive exercise - but they live on throughout the internet! I have collected the images here - and would like to say " Thank you, River Lynn Bailey ". This is a great, amusing and educational resource for everyone.

Right. I have to get this off my chest. A follow-on from my habitual coding observation in my previous article . How many people habitually write Java code like this? (Clue: I see it a lot) public class Article { private String title; private String author; private List tags; public void setTags(List tags) { this.tags = tags; } public void setAuthor(String author) { this.author = author; } public void setTitle(String title) { this.title = title; } public String getTitle() { return title; } public String getAuthor() { return author; } public List getTags() { return tags; } } Then you can create an object an use it with something like: Article article = new Article(); article.setAuthor("Cam M. Bert"); article.setTitle("French Cheeses"); article.setTags(Collections.asList("cheese", "food")); // etc etc G

One of the most common conversations that I have with clients is about continuous integration (CI) - the discipline of pulling together work done as often as possible, usually after code checkin to verify that the project is still on track (ie "it works"). So how many environments do you need in order to get real benefit from CI? Unfortunately the answer is a fuzzy "It depends...". But I always recommend at least 4 for safety/effectiveness. The good news is that if you do it right, downstream environments are relatively cheap to add as the need arises. (I have lost track of how many times I have drawn this diagram in various forms for clients, both in formal training and informal conversations. I am quite glad that I have finally managed to capture it onto one A4 sheet!) So what have we got here? Build & unit test This is the initial stage, normally triggered by a developer checking code into a version control system. It checks out the code

Mike Hill has written an excellent article titled " How TDD and Pairing Increase Production " An excerpt: "If you want more production, look first to raising your internal quality. ... All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down. If you want to work as fast as you can, you want to work with clean code. Period." There are many more thought provoking truths in there. Read it! It might just change the way you write code.

There's a buzz in my tiny corner of the industry at the moment. " Software Craftmanship ". But what is it exactly? I for one am not sure. Currently it seems to be all things to all people, but with a common theme of quality running through it. Some think it's fairly hardline, others think it needs to be flexible and all-encompassing. But one thing it's not - it's not just about agile or lean processes and practices (although personally I think they are a significant step in the right direction). So what the hell is it? Here's an attempt at defining what it needs based on existing professional engineering and other disciplines that could be considered craftmanship (for example, carpentry, surgery, architecture/building and so on). It needs a set of ethics. This is what keeps you honest and provides a structure on which you can base decisions. Ethics tell you when to walk away when you are being asked to compromise too far. They provide the line in the sand

A bug does not definitely exist or not until you exercise the code. You can either let your users find it, or you can write tests to flush it out. It's your call.