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 😉
I have had a few emails from readers of this blog over the last week asking if it has been abandoned. The answer is No. I was off work for a month after having surgery and then on my return to work I was pretty snowed under, but I am definitely continuing to write posts. I am currently half way through my next large article on Service Oriented Architecture Design and will have that posted over the next month.
In the mean time, thank you to everyone that reads this blog regularly. Over the past 3 months, traffic has been rising quite a lot, far more than I ever anticipated, so I will definitely be continuing with it. I have lots of interesting posts in the pipeline, as well as expanding the training section.
Build the right Product – Using a continuous deployment model helps to ensure you develop the right product by ensuring you get rapid feedback from your business partners and stakeholders.
Earlier Benefits – Continuous delivery enables you get benefit out to your business/customers earlier so they can take advantage of features sooner rather than later in a big bang deployment.
Ability to React Quickly and Respond to Change – If youhave a continuous delivery system set up and are used to deploying continuously you can respond to changes in requirements more quickly or fix and deploy bugs sooner.
Innovation – The continuous delivery process enables you to work closer with the business. This closer working relationship means you have different kinds of people and skillsets working closer together. This can lead to different perspectives on problems which can lead to innovation.
Reliability and Stability – If you release your projects continuously you are repeatedly exercising your deployment process. This continual deployment and the fact you can react to change quicker leads to more reliability and stability.
More Efficient / Save Time –By automating your deployment process you can make your development team more efficient as they don’t have to deal with deployment issues as often leaving them more time to work on the good stuff, writing code!!!
Strategic Impact – A combination of all of the above gives you a strategic advantage over competitors as you can release more features sooner and fix problems sooner.
I can’t stress the benefits of getting continuous delivery working. If you are working on a new project and don’t have to deal with legacy code/systems then this is easier to achieve. If you have to deal with a huge knotted legacy estate like my developers have had to do, then getting a good continuous delivery pipeline running is harder, but can be achieved in stages.
This is what we did. We got automated builds going, and then had installers being built at the end of the builds. Then we worked on the tools for deploying to different environments. We have continuous delivery working into test environments but our next stage is to get this working for production deployments.
This is made harder for us as being part of an American Financial institution we are subject to the Sarbanes Oxley regulations which mean we have to have clear separation of concerns between development and production system, but we are looking to tackle this.
There is a very good book about this subject that I highly recommend reading. The book is called Continuous Delivery by Jez Humble and David Farley. Currently with the team I work in we are using TFS and its built in tools to manage our continuous delivery process with an auto deployment tool written by some of the guys on my team, but we are considering moving to just using TFS as a source repository and using Team City + Octopus Deploy to manage builds, packaging and deployment.
Does it build? Yes then continue, No then stop the code review.
Run the unit tests.
Do they run and all pass? Yes then continue, No then stop the code review.
Check the unit test code coverage.
Is the coverage around >60%? Yes then continue, No then stop the code review unless there is a good excuse for the coverage that the review team are happy with.
Check the code metrics (Cyclomatic Complexity and Maintainability Index)
Are the metrics within agreed boundaries? Yes then continue, No then stop the code review.
Run the static code analysis against the agreed rule set?
Are there any warnings / errors? Yes then stop the code review, No then continue.
Once you get to this point, the development practices have been followed and you can proceed to review the actual code.
All of the tools I discussed above are available as standard to developers who use Visual Studio Enterprise Edition, except Resharper/CodeRush etc.
Unit Test Coverage
Whilst you are developing your software you should be writing tests to exercise that code. Whether you practice test driven development and write your tests first or write tests after the fact, you need a decent level of test coverage. This gives you a level of confidence that the code you are writing does what you expect it too. Also, it gives you a safety blanket when you need to refactor your code. If you make a change in one area, does it break something somewhere else? Unit tests should give you that answer.
The screen shot below, shows the Test Explorer view in Visual Studio 2012. From this view you can run all of your unit tests. As of Visual Studio 2012 Update 1, you can group you tests based on pass outcome, length of execution and project. Think of this view as your project health dashboard. If you have a good level of coverage and they are all green, then you can carry on developing. If you have any red tests then you need to work out why and fix them. Don’t let this view lead you into a false sense of security though. You still need to write tests to a decent level of coverage and ensure you are testing the right things.
You can check your test coverage very easily in Visual Studio. First you can click the little drop down ‘Run’ menu in the Test Explorer, or you can open the ‘Test’ menu in Visual Studio, and then open up the ‘Analyse Test Coverage’ and select ‘All Tests’. This will give you a view similar to below.