When I look back at last years look at 2010 my blogging rate has not changed much (I suspect this is largely down to using Twitter a lot) but my interests this year have developed a lot further.
My view on 2010 would be that Microsoft would commit more to OSS, while I wanted to see more hires from that audience and more projects on Outercurve foundation instead there has been support for JQuery and Gems (aka NuGet). I would love to see more from Microsoft on the OSS front in 2011, Outercurve could become like the Apache foundation with enough support.
Staying on the Microsoft front I predict that 2011 will bring the following.
- C# 5.0 will go RTM (still no MOP though)
- The next release of VS will go alpha or early beta
- MS MVC 4.0 (I think by Mix time) and maybe this release will get a command line.
I also suspect that Microsoft will want to target the tablet market with WP7 in 2011 (Mix 2011 maybe…).
I also predict the following
- Java will fork with Apache\Google. Oracle will then take them to court and the whole thing will boil right through 2011 (Java have had enough court cases, come on guys). Java and the JVM will sadly not move forward at all in 2011.
- Android will cause Apple a serious headache, both the smartphone and tablet market will see figures cut from Apple share. By the end of 2011 the current 70% apple market share will be 40-50%. As the features, performance and price of Android devices gets ever better Apple will be left out in the open.
Lastly after 7 years I intend to move this blog away from weblogs. In 2011 I will be exploring Java, Ruby\Rails and Android and such subjects don’t make sense to talk about it here.
See you in 2011.
MbUnit\Gallio 3.2 was released today and includes many new features and fixes.
The release notes can be found here, you can find the download here.
Icarus continues to grow as feature rich GUI for running unit tests, this feature has added a search feature as well a number of bug fixes.
New command line option to allow reports to be compressed as a Zip.
We also offer this support in the MsBuild task, CCNet task and PowerShell integration.
As noted in previous posts Gallio has offered integration with the VS unit test tools for some time now, in this release we have added support for the new VS10 Data Collector feature.
You can now configure TD.NET options from within the Gallio control panel.
This release has added a number of new features to MbUnit.
The Mirror framework replaces the reflection support that has existed since v2 and offers a powerful way of testing non public members.
Also see this post from it’s author.
Brand new XML Assertions
Fluent syntax for the Data Generation framework.
This release was made possible with contributions from Jeff Brown, Yann Trevin, Graham Hay, Vadim Kreyin and Andy Stopford. The core team also wishes to thank the help of Euan Garden, Bruce Taimana and Michael Koltachev.
Finally, with this release I am resuming my role as MbUnit’s poobah and help drive Gallio and MbUnit on to the next milestone.
The O in the SOLID principles, Uncle Bob explains this simply
A class and it’s component parts should be Open for extension and Closed for modification.
To follow this principle let’s take the clock object again. We know from SRP what parts are responsible for what and when we mix these we can create new kinds of clocks. Certain things may be internal to a clock part such as the clock face.
The clock face may be composed of several different things such as the display, hands and numbers etc. If the face was to change from say roman dail to micky mouse we don’t want to have one clock face object that we have to keep changing\rewriting for every different kind of face (you risk code duplication) but instead give it (extend it) the component parts it needs. A mickey mouse clock face would have mickey mouse hands, display and numbers but would display the hours\minutes via the rest of the clock object in the same way as the roman dail or any other type of clock face.
In software terms the way we achieve OCP is with either simple inheritance or dependency injection. More on these in later posts.
Matt Ward has a sample that shows how to write a plugin for Gallio that can then integrate with the SharpDevelop IDE.
The S in the SOLID principles is one of the most simple and most important principles.
Let’s take a simple example, one of a clock. A clock might have lot’s of parts, parts that keep time, that tell you what the hour and minute of the day are etc.
A clock might also have other parts such a display to output the time. In OO the display would inherit the other clock parts to obtain the time and then display it. In an analouge clock this might include the clock face, hour hands, minute hands etc. In a digital clock this might include an LED display etc.
Now we ask the question while both displays are are concerned with the display of the time, the analouge clock is not concerned with the digital clocks LED display and the digital clock is not concerned with the analouge clocks hour and minute hands etc. Each display is concerned only with it’s own display types and does not need to know nor bother with anything else. Both displays are not concerned with keeping the time, that is left to other parts of the clock, the only thing the display is concerned with is showing you the time.
If an LED display was concerned with clock hands it would break the SRP principle.
If we take this back to your coding we apply the SRP principle to everything from class to method, making sure that each is focused on one thing.
Technical Debt is subject that is very close to my heart, I first heard of the concept at a great session that Gary Short gave and ever since I have found ways of finding and addressing the problem. So what is Technical Debt?
Technical Debt is a like any other kind of debt.
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… 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, OO or otherwise. – Ward Cunningham.
So what causes Technical Debt, for that I’am going to borrow Martin Fowlers great quadrant diagram.
Every hack, work around, bad piece of code builds technical debt. So what it is the cost, an image from this great article sums it up well.
The real cost of Technical Debt is that for every bad piece of code, it can cause problems to your customers and cost you and your business money. It can cause you defects (and in some cases) cost the business money. It can takes other coders time to find and fix the problems or work with the code, time is money.
As time goes by and theh debt builds up the cost also goes up, the further the problems, the harder to resolve and the bigger the cost.
I’ll move into approaches to resolving technical debt in later posts.
Uncle Bob outlines this concept well in in the 97 rules book.
Leave the code a little cleaner than you found it
In other words where you can improve and make better the code you are working in. In legacy code you should follow this concept with a blazing degree of intent. By its very nature legacy code needs to be better and no matter what you are doing or where you will need to improve it.
In legacy code it is always a temptation to leave behind the small things. Let’s take for example a small function that has two ‘return’ exit points. While you can agree that such a small function may not cause too many problems and changing the function violates YANGI you can fall into a trap. Some else comes to that function and follows it’s structure to add yet more exit points. Soon the function carries more technical debt weight then you came across it. With the boy scott rule you leave nothing behind, if you see it might cause problems not only for you, now, but also for the team in the future you make it better.
I’m going to write more about technical debt at a later date but it is a subject also worth covering at a legacy level.
Legacy code has a high level of technical debt by it’s very nature, in following the series so far the debt is being managed and repaid. The danger you face is adding to the technical debt and never overcoming the debt mountain.
Consider very carefully the single responsibility principle, legacy code tends not to follow this principle and in the refactoring work your first aim is to strictly follow this principle. Failure to do so can result in code mixing concerns and in turns causes technical debt.
If you start to work with the code more, adding new code and failing to follow this principle can cause technical debt.
So why technical debt? Consider that when you leave the code behind and some else picks up the code if the code still has problems those problems need to be overcome, that takes time, resource, money (all debt to you, your project and your company). I do hear sometimes debt can be occured if a programmer is unable to work with the principle, such issues should be measured and balanced against the debt (what is the real cost).
Someone creates a class or series of classes for something, the classes are big in size with large complicated methods. The effort is a sea of technical debt for the entire team but in the thick of the daily chaos it is lost. With out the coder talking to the team, with no team code policy and no code reviews (and action points) it remains. Pretty soon the team forget about that code.
A few weeks\months\years goes by, some of the team may have left, some may remain but business asks for the team to add to that code. The team is now looking at a black hole, no one knows how it works, what it does, what it is for, it is a smelly hell hole and the deadline is fast approaching.
The team now tries to change the code, with no approach at unit tests or refactoring in fear of breaking the black hole the team do just that and the business have just lost money.
If you are faced with a black hole you need to look back over my series, even a black hole in what might seem like a clean unit tested application. Don’t be fooled into thinking that legacy code does not apply to your code base.
The next stage is don’t let blackholes in your codebase. Effective code reviews, team communication and good overal team coding policies will really help. Even if you are faced with a deadline do not let them appear, stop, take stock, what can be done and who can help. If you allow them through they will grow and grow and grow and the technical debt will hit you like a tidal wave soon enough,.
During your refactoring cycle you should be seeking out the hard dependencies that the code may have, examples of these can include.
Classes that service these kind (or code that can be abstracted to a class) of these kind of dependencies should be wrapped in an interface for easier mocking. If you team starts refering to the interface version of these classes the hard dependency will over time work it’s self free.