Duchess

C++, Java and .NET – Lessons Learned from the Internet Age, and What it Means for the Cloud and Emerging Languages (Cameron Purdy)
The top 10 reasons why Java has been able to supplant C++ as the dominant programming language are: automated garbage collection (meaning you can build libraries without worrying about memory management), the fast build process, the simplicity of source code and artifacts, the binary standards (cross-platform development), dynamic linking (no more dll hell), portability, standard type system (primitive types and java.lang library), reflection (again necessary for making libraries), performance (due to garbage collection and multi-threading), and safety (no more pointers and therefor no more buffer overrruns). On the other hand there are 5 reasons why Java has not been able to supplant C++: Startup time (many classes have to be loaded to run the simplest of programs), memory footprint, full garbage collection pauses, no deterministic destruction, and barriers to native integration. Despite these last five reasons, the shift to Java has been made anyway. Why? Because the internet came along. Suddenly applications were run in a browser and no longer on the client. Suddenly those five advantages C++ had weren’t as important anymore. And then they came up with scripting languages that were a lot more simple as well. Many of these run on Java’s JVM.
But now we are shifting to Cloud computing and that is where Java still misses a few aspects. When it comes to the virtual machine for example, we’re going to need a lower memory footprint and predictable garbage collection pauses. So the conclusion is that either Java will step up to the new challenges or it will get replaced by another language that does.

Guiding Your Personal Life: Plan-driven or Agile (Linda Rising)
Around 1800 the industrial age began in England. Suddenly people moved from the farm to the factory. This change was inspired by many elements. First of all the clock was becoming widespread in it’s use, which gave people an accurate way to tell time, allowing people to make punctual agreements. Second, caffeineated beverages were discovered, replacing beer as the main beverage. As water had to be boiled for making tea and coffee, it became largely safe to drink. This coupled to the rise of factories led to the lifestyle we still have today. This lifestyle, however, isn’t very natural. Until the industrial age the time for sleeping was dictated by the sun, allowing people more sleep in winter when it was neede more. Furthermore, caffeine isn’t very healthy either as it blocks the natural hormone that tells us we are sleepy, meaning we sleep even less. More and more, sleep is seen as something that is a waste of time. While it has been proven that without adequate sleep, we are not at our best, physically, mentally or emotionally. Even worse, without adequate sleep our brains show visible signs of premature aging. Caffeine will make us feel better and have us believe that we perform better, but the effects are no better than what a break would allow. Even more, caffeine only improves vigilance tasks. Tasks that require prolonged attention and little physical activity, like tightening bolts on a production line. And worse yet, for complex tasks only extroverts’ performance improved, while introverts tended to get worse.
Extensive experiments have been conducted that prove that sleep improves our learning capacities. Even just a short nap helps a lot. Sleep is divided up into cycles that consist of several phases. So maybe we should make sure that we use similar cycles for our activities. At the very least we should experiment with these ideas to see what works and what doesn’t.

Organizational Patterns and Scrum: Fine-tuning your Agile Implementation (Gertrud Bjørnvig & Jim O. Coplien)
The presentation started off with a little roleplaying where several people from the audience got a hat with a role attached to it and had to act out what they thought were the distances between them and the other people on the team. Through this play several of the patterns from the book Organizational Design Patterns were shown. After this a short history of patterns was discussed, along with the definition of a pattern and what Scrum is. The statement was that Scrum is very complex and that it should contain a whole slew of patterns, and that if Scrum isn’t working properly for you, you might want to investigate these patterns to find out how they can help you get to where you want to be. The conclusion was that Scrum is a pattern language, where the patterns provide insight and encouragement to fix broken Scrums. The patterns can also be used as an incremental path to Scrum adoption. So if you haven’t read it yet, go read Organizational Design Patterns by Coplien and Harrison, as it contains essential knowledge everybody who wants to change their organization should have.

Deliberate Practice in Software Development (Mary Poppendieck)
In sports and music it is well known that you only get to be an expert if you practice a lot. And not just any practice, but deliberate practice. The four pillars of deliberate practice are having a mentor, being challenged, getting immediate feedback and being dedicated. Mentors in IT should hire and grow people, review and guide work, set technical standards and ensure technical excellence. Unfortunately, most companies don’t have mentors. They usualy assume that product champions are enough. But a product champion is more like a conductor than like a music teacher, necessary, but not enough to ensure quality. In order to be challenged, you should get to do hard things and be able to do them frequently. Only too often you don’t get challenging work assignments as assignments are handed out to the people who are already good at that type of work. And when it comes to feedback the programmers are often kept at arms lenght of the customers, so the feedback is usually indirect. A good example of direct feedback is the feedback you get when you work on an Open Source Project, it is immediate, constant and detailed. And finally, skill development takes time. Time spent in the same place, as rapid job movement doesn’t develop skill. Time to learn without interruptions. Time to invent, practice requires the time to make mistakes.

The IT Division Refactored (Richard Durnall)
After quite a few years as an industry we’re still seeing over 60% of all projects in IT fail. This might be in part due to the way our IT divisions are structured. We are still working in a structure that was pioneered to manage a lot uneducated people. Despite the fact that we’re no longer uneducated and that we’ve known for quite some years that this model is quite inefficient for our current needs. All of this because managers believe that it is better to fail conventionally, than to succeed unconventionally. The current model is to start at the top, appoint managers by specialisation, allocate people to divisions/teams, communicate a strategy, determine performance targets, define the delivery process and then to engage the customer. A better model would be to start with the customer, develop a strategy, design initial processes, define process metrics, structure the organisation to support these processes, appoint process managers, and to end at the top and then to adapt and improve. Things to keep in mind are to improve the process first and only then to automate. Otherwise you will automate things that weren’t working in the first place. You should also allow for change. IT systems are corporate concrete that will freeze the processes. Systems Management Theory resolves the challenge of how to do Agile at scale.

Value Management (Evo) with Scrum development (Kai Gilb)
One of the reasons why selling Agile development to managers is so hard, is that the agile manifesto is all about the developer and not about delivering value to the stakeholders. The value management process contains eight steps: identifying the stakeholders, finding and specifying quantitatively the stakeholder values, prioritizing the possible solutions, breaking the winning solutions into smaller entities and packaging them, developing the packages, delivering to stakeholders, measuring the changes, and finally learning and changing the behavior. Scrum is only about the four steps from solutions to delivery. The value management cycle and the development cycle are both equaly long -1 to 3 weeks- and should take place at the same time. To implement value management you need to determine the business values, refine those in stakeholder values, refining those in product values and turn those in a prioritized scrum list. This doens’t have to be a top-down approach, as long as the end result is that the lists are defined. So if the problem is that a certain service is too slow, the developers are asked to come up with as many solutions as possible to solve this problem and then to present these to management in a value decision table, containing information on how much better the situation will become, how much resources it will cost etcetera. The greatest challenge to get this working is to get the business owners and steering committees to stop thinking in technical solutions. Business owners should instead focus on what their real needs are and the steering committee should sign off on value improvements, so the developers can come up with the best technical solutions that will give maximum product value improvements. Some case studies of where value management has been used show astonishing results.