We are now at that time of year where everyone is making New Year’s resolutions about how they want to better themselves by losing weight, getting fitter etc. It is also important to think about what you want to do with your career and there is no better time to think about this than New Year.
New Year is a good opportunity to take a good hard look at what you do for a living and think, is this what I want to be doing? Does this job still have the same level of opportunity that it initially did when I first took it? If the answer is yes, then great, but if the answer is no, maybe now is the time to look for a new opportunity, as getting a new opportunity elsewhere for yourself even opens up opportunity for someone who is taking over your job.
I don’t mean for this to sound negative about whether you are happy in your current job, but maybe New Year is a good time to evaluate things.
2013 has been an interesting year for whistle blowing about surveillance from the American and British governments. Earlier in the year Edward Snowden, a former NSA technologist, decided to put his own life on the line and leak a huge cache of documents about the NSA’s surveillance capabilities against its own people in the USA. This goes against the 4th amendment in the constitution that prohibits unreasonable searches and seizures and requires any warrant to be judicially sanctioned and supported by probable cause.
The notion of surveillance is a complex topic. There are a lot of bad people out there that want to cause America, Britain, and Europe a lot of harm, and we need a way to keep tabs on these people. In this case I believe surveillance is justified. There will always be threats from domestic threats which also need to be monitored. The question here though is, have our governments crossed the line with the mass data collection that they are doing. In my opinion yes they have, but now this is all starting to get out in the open, maybe something will start to be done about it, hopefully. This all really started when George Bush gave the NSA the remit to collect this data after the September 11th attacks against the USA.
Today is Coding in the Trenches, first birthday. This time last year I had the idea to start the blog to share my thoughts on Software Development, Architecture and Leadership. It has been a very enjoyable and successful experience. My readership is growing each month and the reader numbers have exceeded what I thought I would get in the first year, so I look forward to seeing what next year brings. Although I didn’t really start posting properly to the blog until the new year, it was the 18th of December that I had the idea and set-up the basic blog and template.
Since I wrote my article recently about Google’s 9 principles of innovation a reader over on Reddit pointed me to a resource on some more good design principles. These are the 10 Principles for Good Design by a German industrial designer Dieter Rams.
Dieter Rams introduced the idea of sustainable development and of obsolescence being a crime in design in the 1970s. Accordingly he asked himself the question: is my design good design? The answer formed his now celebrated ten principles.
Whilst Dieter was an industrial and product designer, his principles can fit anywhere where good design comes into play. In the rest of this article, I will explain what the 10 principles are, and how I think they fit into software development.
The principles in this article are very useful for software developers and designers, but this is also very relevant for technical leaders. As a leader it is good to try and push your teams to make sure they are thinking about the end user. Traditionally, software developers make lousy designers (not all of them before I start a flame war), but aesthetic design, generally, isn’t something that comes naturally to programmers. Therefore having principles like these is great for giving you pause to reflect on how your system / application affects your end users.
The different product images below are examples of products designed by Dieter. Those of you old enough may recognize a few!!
Whilst doing my daily trawl through the internet and Reddit pages, I came across a very interesting talk at the San Francisco Dreamforce Summit where Google’s Chief social evangelist, Gopi Kallayil talks about Googles 9 principles of innovation. Please do go and watch the video as it is a great insight to the inner workings of Google, but here are the 9 principles summarized here.
Innovation comes from anywhere
An idea for an innovation doesn’t have to just come from your super star employees. Ideas can come from anyone. There is a really good example that Kallayil mentions where an onsite doctor at Google had idea that if someone talks about suicide in a Google search that the first item in the search results should be the phone number for the National Suicide Prevention Hotline. The call volume to the helpline went up 9% after that. This is a great example that an idea for an innovation, no matter how small, can have a big impact.
Due to the impact of this one small change, they have now rolled this type of change out across the world. In the screenshot above you can see where it shows the phone number of the Samaritans.
A colleague of mine sent me an article on ArsTechnica that was a short discussion on whether it is a good idea to write tests for legacy code. This was made up from a collection of posts on Stack Exchange. The original question was as follows:
“Suppose one had a relatively large program (say 900k SLOC in C#), all commented/documented thoroughly, well organized and working well. The entire code base was written by a single senior developer who no longer with the company. All the code is testable as is and IoC is used throughout—except for some strange reason they did not write any unit tests. Now, your company wants to branch the code and wants unit tests added to detect when changes break the core functionality.
Is adding tests a good idea? If so, how would one even start on something like this? “
Original question posted by Paul over at Stack Exchange
It’s a good question, so I thought I would write down my thoughts on it. I am a firm believer in Test Driven Development (TDD) and this is much easier when you are working on a nice new green field project (writing a new system). Unfortunately we don’t always have the luxury of working on new systems and we have to maintain older legacy systems, or brown field applications. If you have a large brown field system, I personally do not think there is much value in getting your team of developers to sit there and wrap the whole system in tests. Whilst it may feel nice to know the application is covered in tests, the level of effort and expense in doing so is likely to be very high indeed. If the system has been around for a long time, then it is most probably working fine and your users are happy with it (this isn’t always the case, but is more often the case).
What I do feel is valuable though is adding some tests when you need to change/extend part of the code base. As the system already exists and you can’t reliable determine that the code is doing what it should be doing you can write what Michael Feathers describes in his book “Working Effectively with Legacy Code” calls characterization tests. A characterization test is:
I have created a Facebook Group for this blog where I can make announcements, and do smaller posts about whats on my mind in the world of software development, architecture and leadership. It would be great if you can come on over, click like and participate in a little friendly banter. Lets go all social 😉