Duchess

Scaling up Agility: The architected Agile approach (Barry Boehm)
The need for agility is ever increasing, but at the same time there are a lot of laws etcetera that require auditing of your code. Unfortunately, auditors want the exact opposite of what the agile manifesto says we need to do. One way to balance the discipline the auditors want with agility is to make decisions based on risk. For some issues developing in an agile way poses a risk. But developing plan driven brings other risks. A balance between these two has to be struck. Four case studies showed that the balance can be found succesfully.

The Return of the Son of ‘Working effectively with legacy code’ (Michael Feathers)
In the five years after writing the book, Michael Feathers has done a few more discoveries that have helped him when working with legacy code.
Once a large system gets too many global variables, it is hard to get rid of them and often the points of use for singletons are too scattered. Componentization can help by gathering such variables in repository or factory hubs. When breaking dependencies, you should alway be pragmatic at what level you break them. Recognizing seams (places where you can change the behavior without editing the code) can help a lot when bringing code under test. Another thing to think about when developing for testability is to never hide a test unfriendly feature (TUF) like file IO or database access within a test unfriendly construct (TUC) like a static method or constructor. Finally, code should never lie. So don’t dynamically replace code in the source and always name methods and classes well.

Clean Code III – Functions (Michael Feathers channeling Robert C. Martin)
Quite often code will contain long functions that have too much going on in them at too many different levels of abstraction, with strange strings, odd function calls and doubly nested if statements controlled by flags. This renders the code very hard to read, let alone understand. With simple method extractions, some renaming and a little restructuring such code can be altered to capture the intent of the function quite easily. In order to have your functions understandable they should: be small (as in only one line in a block), do only one thing, have a descriptive name, have no more than three arguments (and the fewer the better), have no side-effects (from what the name says it should do), separate commands from queries (a getter should do nothing other than get something) and prefer exceptions to returning error codes.

Old School – Techniques that still work no matter how hard we try to forget them (Keith Braithwaite)
If IT were a person, it would be diagnosed with ADHD (we have difficulty retaining focus on the job at hand and we are easily distracted), retrograde amnesia (we don’t recall our past) and OCD (we follow rituals independent of their effectiveness). Analysis, architecture and modelling have gotten a bad name due to people misapplying them. Analysis is all about understanding. And since we had forgotten all about it, we had to reinvent it with behaviour driven development and domain driven design. Architecture is a bit over everything and nothing, as no-one quite agrees on what it is. It seems to mostly have something to do with compromise, communication, habitability, reconciliation, comfort and easy of construction. So despite the bad name, every system has an architecture, so it might be worth knowing how to talk about it. Modelling in IT seems to be intent on including every single detail into the model. This despite the fact that all useful models in for example engineering are useful for what they leave out. They are intended to be used to answer a question more quickly and easily than the real thing would.

Software Product Lines: Today’s impact and tomorrow’s potential (Linda Northrop)
Most organizations produce families of similar systems, differentiated by features. So a reuse strategy makes sense, but traditional reuse strategies have had little economic benefit. Looking at the history of reuse, the focus was small-grained, opportunistic and technology-driven. The results did not meet the business goals. Product lines – building a family of products from interchangeable parts – have existed for centuries, from Chinese building codes to McDonalds. A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Core assets include for example the documentation, the test plans and the code, but also the people and many other assets. Besides these assets a production plan is used that reports how these assets are to be used together to create products. The core asset base forms the architecture. In some cases a product line will not be the right way to go, so there should always also be a scope definition and business case. The SEI has developed practice areas – bodies of work or collections of activities that an organization must master to successfully carry out the essential work for a product line – and divided these areas into patterns. Using a Software Product Line results in significant organizational benefits including increased quality, decreased cost, etcetera.

xUnit Test Patterns and Smells (Gerard Meszaros)
Sadly, programming experience, xUnit experience and testing experience don’t always add up to robust automated tests. Yet maintainable tests are crucial to success, because tests need to be maintained along with the rest of the software and the testware must be easier to maintain than production software, lest it be left behind and the value drops down to zero. There are three common kinds of test smells that indicate that the test code doesn’t have the quality it should have: code smells (visible problems in test code), behavior smells (tests behaving badly)and project smells (testing-related problems visible to a project manager). Where code smells may be root cause of behavior and project smells. To solve these problems, there are test patterns. A code smell occurs when the tests are hard to understand, or if they contain coding errors, or when they are difficult of impossible to write. Common code smells are conditional test logic, hard to test code, obscure tests, test code duplication and test logic in production. Behavior smells occur when a problem is seen when running the tests, test that are failing when they should pass (or vice versa), or if the problem is with how tests are coded. Common behavior smells are slow tests, erratic tests, fragile tests, assertion roulette, frequent debugging and manual intervention. A last warning should be that you have to be pragmatic, not all smells can be eliminated. A catalog of smells and causes gives us the tools to make the decision intelligently and eliminate the smells when we choose to do so. So beside the aformentioned experience, you also need to design for testability, take out the test smells, use test automation patterns and pay fanatical attention to test maintainability in order to write robust, maintainable automated tests.

Energy-efficient warehouse-scale computers (Urs Hölzle)
Future computers will either be very small or very large, with little inbetween. Therefor the need for energy efficiency research becomes ever greater. In the past 30 years the electricity output in the US has doubled. But in the last five years the electricity usage in servers in the US has doubled. Fortunately a lot is done to bring the numbers done. The carbon footprint of IT is a lot smaller than the reduction in carbon emission caused by using IT. While energy costs may not be dominant, the energy related costs are equal to server costs. Computing might become more expensive despite CPUs getting cheaper and faster as the cost of electricity isn’t falling and the cost of buildings isn’t falling either. The total efficiency is the computing efficiency times the server conversion efficiency times the datacenter efficiency. The server conversion efficiency can be brought down by buying/building more efficient servers. Datacenter efficiency can be reached by building efficient datacenters. (Google has a nice movie about how they achieved this with their warehouses.) Finally the next big gains will have to be achieved in computing efficiency. Computers will have to be made to use less energy when they are idle, because while household computers can be turned off, this is not the case for servers. This last part is the main task for the future.