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.

Classes, Jim, but not as we know them (Simon Peyton Jones)
Haskell is a statically typed, purely functional language that was designed 20 years ago by a committee of academics to be a research language. Most new programming languages never catch on and die after about a year having only ever had one user. Succesful research languages live somewhere in between five to ten years having up to a hundred users. Truly succesful languages don’t die out at all and accumulate millions of users. Examples of this would be C++, Java, Perl and Ruby. On the other side of the spectrum are committee languages, that never have any users at all. Haskell on the other hand seems to defy this category. After about five years it had a couple thousand users and at the moment this number even seems to grow to tens of thousands. According to langpop.com it is hardly ever used, but on the contrary it is one of the most talked about languages. This popularity can be traced back to some good ideas like purely functional, controlling effects, laziness, concurrency and parallelism, domain specific embedded languages, sexy types in general and type classes in particular. As you can pass functions into Haskell functions, how can you make a general equals method that works no matter what arguments you pass into it? Unsatisfactory solutions are local choice or to have the function work for everything except functions. To solve this problem, Haskell has introduced type classes. A type class is an indication of the type of argument you expect: this function works for any type ‘a’, provided ‘a’ is an instance of class ‘X’. For every type class, there is a class definition that says what the operations for that type class are. Then an instance declaration for a type T says how the operations of that typeclass are implemented on T’s. All this scales up nicely, allowing you to build big overloaded functions by calling smaller overloaded functions, and building big instances by building on smaller instances. Even literals can be overloaded, allowing 1 to mean fromInteger 1. Type classes have proved extraordinarily convenient in practice for cases like equality, ordering, serialisation, numerical operations, monadic operations and much more. Comparing type classes and object-oriented programming, it must be noted that type classes use type-based dispatching, instead of value-based dispatching. A Haskell class is more like an OO interface than a class, as it says what operations the type must support. The advantage of typeclasses over interfaces is that existing types can retroactively be made instances of a new type class. Haskell on the other hand has no sub-typing, so if one of the arguments of a function is a Tree, then it must be exactly a Tree, and nothing else. The ability to act on arguments of various types can only be achieved via type classes, which means that you must anticipate the need to act on arguments of various types.

Agile modeling and documentation best practices (Scott Ambler)
Agile modeling is a collection of practices based on several values and proven software engineering principles. The models this produces are as simple as possible so they are still understandable and can fulfill their purpose, but also so that they are just barely enough. When trying to scale agile delivery suddenly a lot of factors come into play like team size, compliance requirements, geographical distribution, enterprise discipline, technical complexity and organizational complexity. Agile Model Driven Development tries to address these issues. AMDD starts each project with iteration zero where the intial requirements and the initial architecture are envisioned. This should take a few days at most. Then every iteration starts with iteration modeling, which should take a few hours at most. This modeling is necessary to plan the iteration. When the resulting model isn’t specific enough for certain issues, this is followed up with just in time model storming, which should take a few minutes at most. And this in turn is followed by Test Driven Development. All of this modeling takes place under the assumptions that it is only just barely good enough and that it happens as late as possible so you can document stable things and not speculations that will prove false. You should prefer executable specifications over static documentation, as static documentation has a tendency not to be maintained. As for the quantity, you need a bit more than the extremists may care to admit, but a lot less than the bureaucrats realize. A big problem with documentation in most organizations is that it isn’t very effective, as the chance that it is correct, read, understood, followed and trusted are ever decreasing respectively. So in conclusion it should be realized that a model isn’t necessarily a document, that modeling is a key scaling strategy for agile development projects, and also an important part of every software process (including agile ones), and it’s an important communication technique. You’re likely doing a lot more modeling than you realize, but as you don’t realize you’re doing it, you could be a lot better at it.

Adventures of an Agile Architect (Dan North)
Once upon a time there was an agile architect named Dan. He was asked to coach a non-agile team into being agile. When he arrived he found that technically the software was SOA gone bad. All sorts of clients were coupled to all sorts of services through a WSDL. There was a whole lot of duplication too, as lots of the services did basically the same thing, but using different parameters. Operationally it was a complex, flaky infrastructure, with lots of EJB’s running in a non-standard old version of JBoss. And finally organisationally, the developers lived in silos, arguing vehemently for their prefered solutions, without listening to each other. The story has a happy ending however, as he was able to guide them into implementing a SOA as it was meant to be with clear context boundaries. Operationally they ended up with deterministic deployments and a product that was stable in production. And organisationally they had a happy team that staid happy even after he left. But before he got there, he set out to listen to all the developers. And was blown away by the realization that they all wanted the same thing. This made it a lost easier to determine and set a strategy. He warned the management that he was about to change things to remedy the situation and that it would make a lot of noise. They agreed on the condition that he really would fix things. He then set off to change the culture. It turned out that daily standups had already been tried, but that they had failed to be effective. Instead he set out to have a daily discussion about what the best possible today could be. With this and similar measures he was able to get the whole team on board to set off to become agile. To fix the technical mess the software was in, he introduced the command pattern. And when they chose a wrong direction in the implementation of said pattern he found out after taking the blame for that mistake that the team was now more willing to start experimenting, as nothing had happened to Dan after admitting the mistake. After the command pattern was in place they got rid of the EJB’s as they really didn’t need them. When the EJB’s were finally gone they introduced bounded contexts to separate the different areas in the software. This resulted in the fact that every piece of the code now had a logical place where it could be found. And when all this had been done they opened up their code to other teams and spread their way of working throughout the company. The lessons Dan learned from this project, are the ones he told me and the same as I’m going to tell you now. First of all, there is always a reason why the organisation and the software are in the state they are in. A lot of choices have preceded the endresult, choices that were most likely the best possible choices that could have been taken at the moment. Second, in order to make everyone aware of those reasons, every team should have a shaman that can tell the stories with that history. If a team doesn’t have a shaman, you should either find one, or learn how to be a shaman yourself. The third lesson was to strip away everything you can, right until the moment that it breaks (at which time you have to put the last bit back). Superfluous code obfuscates the story of the code and makes it much harder to understand. The fourth lesson was that you can’t buy architecture. You can buy tools if necessary, but architecture has to be made to fit the situtation. Trying to hammer your situation into an existing architecture results in bad code and an unhappy team. The fifth lesson was to use transitional architectures. Sometimes a piece of code is too complex to be changed all at once. Transitional architectures are architectures that are far from perfect, but that are a step in the right direction. You should take care to communicate to the rest of the team that this is only a single step, and where you intend to go. And the final, and perhaps the hardest, lesson was that life moves on. When you leave a team they’ll probably make decisions you wouldn’t have made and that you might not agree with, but that are the best they could make.

Kanban vs and Scrum – Making the most of both (Henrik Kniberg)
Scrum in a nutshell is to split the product, the organiztion and the time to go from a large group spending a long time building a huge thing to a small team spending a little time building a small thing but integrating regularly to see the whole. A typical evolution from waterfall to Scrum goes through the ScrumButt phase. Kanban in a nutshell is to visualize the workflow, limit the work in progress and to measure and optimize said flow. A typical Scrum to Kanban evolution is caused by the fact that for most Operations & Support teams, Scrum doesn’t fit properly and so they evolve to Kanban. Scrum and Kanban are both tools, and like a knife and a fork, it’s hard to say which is best, they are simply intended for different purposes. A comparison should therefor be made to understand them better, not to judge which is best. Scrum prescribes 3 roles, whereas Kanban knows no roles. Scrum prescribes timeboxed iterations, whereas Kanban does not. Both limit work in progress (WIP), but in different ways. Scrum limits the WIP per unit of time (iteration), whereas Kanban limits the WIP per workflow state. Both are empirical, but Kanban is more configurable. Scrum discourages change in mid-iteration, making users wait until the next sprint, whereas with Kanban the user only has to wait until a slot in a certain workflow state becomes available. A Scrum board is reset between iterations, whereas a Kanban board never gets reset.

Turning on a Sixpence – No excuses: Concept to cash every week (Kris Lander & Gus Power)
(Summary taken from the handouts that could be downloaded on above blog)
KEEP IT MOVING: We pursue profit for our clients by continuously delivering features in response to market and user feedback.
KEEP IT WORKING: We take a balanced approach, getting feedback all the time, building quality in and managing technical debt carefully, to move at speed and keep the cost of change low.
KEEP IT TOGETHER: We keep software fully integrated and in a deployable state by checking in every hour or so and getting quick confirmation that everything is working from our builds.
KEEP IT REAL: We keep software grounded in the real world by looking after our own environments, configuring them and optimizing them as part of the whole product.
KEEP IT COMING: We deliver software at a sustainable pace and work towards a visible destination, planning just enough just in time and keeping options open for as long as possible, so we can maximize return for our clients.

Typical Java Problems in the Wild (Eberhard Wolff)
Some common problems keep cropping up in Java code. Ten of these were presented by Eberhard Wolff. They were not necessarily the most common, but certainly with severe effects.
#1 Weak transaction handling.
The transaction is committed, but the exceptions that might occur are never caught, and no rollback is performed. This kind of problem is hard to detect as it only has effects if an exception is thrown. But when it does occur, it can lead to weird behavior and data loss and many other strange effects. Possible solutions are declarative transactions and transaction templates.
#2 Exception design
The three rules “Get all the details from a system exception!”, “Each layer must only use its own exceptions!” and “Exceptions have to be checked – then they must be handled and the code is more secure.” sound reasonable but lead to lots of useless exception handling code and lots of exception types without specific handling of that type. Possible solutions for this are to use more unchecked exceptions (RuntimeExceptions) and to handle only cases you really want to handle. This should be augmented with generic exception handling in the web layer that handles all runtime exceptions that were not handled elsewhere.
#3 Exception handling
Many exceptions are not logged or even swallowed entirely. This is related to #2, if you have excessive checked exceptions, this will occur more often as developers are forced to handle exceptions they can’t really handle. The solution is to at least log exceptions, and to think twice on whether it really is okay to continue in the specific situation. This should be combined with generic handling and improving the exception design.
#4 Architecture mess
Architecture is the decomposition of systems into parts. You should take care not to have overly large or complex parts and you certainly don’t want cyclic dependencies. Because if you do, maintenance will be hard as will concurrent development. Changes will in such a case often have unforeseeable results. Solving this is very hard if you are already in such a mess. So make sure to manage dependencies from the start. Otherwise you are looking at a major restructuring of your application.
#5 Adaptor layer
When performing a service you often encounter cross-cutting concerns such as security, tracing, checking for null arguments, logging, conversions from DTO to internal representations. This kind of code adds lots of boilerplate to each service. Changes to any of these items is very hard, because there are a lot of methods to change. The solution is to use aspects to take care of these cross-cutting concerns.
#6 No DAO
Quite a few people think that as the JPA is a standard, it doesn’t need abstracting away from. But this means that the service will be dependant on JDBC and will throw SQLException, meaning that the persistance will be visible i nthe service layer and beyond. This results in code that is impossible to test without a database, so no real unit tests are possible. The solution is to use a DAO or a repository.
#7 No tests or bad tests
Having no test at all or bad tests means that the code is not properly tested and most likely of low quality. This leads to the code being hard to change. The solution, of course, is to write proper unit tests. But reality has shown that writing proper tests is hard. Therefor you need to educate people on how to do it. Tests should also be integrated into automatic builds. And integration tests and functionality tests should be added as well.
#8 Creating SQL statements
Creating SQL statements by simply concatenating string with parameters is bad for performance, as the statement is parsed every time. Even worse is that this leaves your software open to SQL injection. The solution is to use preparedstatements.
#9 Not designing for performance
If performance is left for the final stages of development, then you can hardly do anything to fix it. As changes might introduce functional errors and it’s too late for the bigger that are necessary. Even worse, the results might be wrong if the performance test is run on different hardware than production. The solution is to get information about the performance requirements before starting on development.
#10 Multiple threads, memory leaks
If multi-threading isn’t done properly, then the system will work in small tests, but production will fail. The problems will probably be hard to analyze and/or fix and they can only be found by code reviews or extensive debugging using thread dumps. The solution is to use WeakHashMap to avoid memory leaks, to synchronize, and to prefer local variables. ConcurrentHashMap should also be considered.

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.

Keynote – Agile@Atlassian – How do we do it?

Good keynote by Sherali Karimov that not only told how Atlassian employs agility, but also gave some pointers on how to implement it in your own company. (Unfortunately I can’t find any slides, but their website seems to offer some of the same content.)

Het modelleren van een canoniek datamodel mbv XML Schema (Modelling a canonical data model using XML Schema)

Dutch presentation by Linda Terlouw about what a canonical data model is and how to implement it with XML Schema. In short a canonical data model is a shared data format for exchanging data between services. It is meant to prevent the rise of lots of translations between all the individual data formats, allowing you to only need to translate your own data to the canonical format. We were also warned that a canonical data model, which models only what is necessary to share information, isn’t the same as a corporate data model, which models all information in the company. A distinction was made between hierarchical and relational models, and it was explained how XML Schema supported both of these options, along with all the pros and cons.

Geef je code wat liefde (Give your code some love)

Dutch presentation by Rob Westgeest and Willem van den Ende from QWAN about how code becomes more maintainable if you give it some love by refactoring. The bottom line is that with small refactorings in the order of ten minutes work, can save you the five minutes you need to read a method. (Which you would need to do again and again.) Presentations by QWAN are always highly entertaining and informative.

Keynote – Mod4j: Open Source Modelling for Java Developers

Another good keynote that introduced Mod4j, presented by Jos Warmer. I was almost surprised to hear that a partner at Ordina still got his hands dirty on code. So it was the right kind of sales pitch, and for an open source product too! Mod4j stands for Modeling for Java, and it is an open source DSL-based environment for developing administrative enterprise applications. (Again there were unfortunately no slides, so I had to take that quote off their website.) At the time of speaking the product wasn’t finished yet, as they weren’t offering all the functionality they wanted, but they had a working version and it looked cool.

Software Quality Automatically Measured

Nice presentation by Gert-Jan Schouten about a cool Maven2 plugin to measure quality and express it with a number. Too bad about the small font of the slides. And the code that was shown was completely illegible due to the small font. But the worst letdown was that the code that was shown wasn’t open source or even for sale. Fortunately somebody from the audience mentioned Sonar, which does more or less the same.

Pragmatic model driven development in Java with smart use cases and domain driven design

This presentation by Sander Hoogendoorn and Rody Middelkoop was slightly too slick for my taste. But as I say, it’s a matter of taste, I bet lots of other people loved it for the exact same reason. In fact, the presentation went so fast, that even with the slides, I can’t quite figure out all that was said.

–

I skipped the last session, as I was pretty tired and didn’t see anything that I thought could hold my attention during this last track. Instead I sat on the lounge chairs on the first floor and talked with some people until they opened the bar. (And kept right on talking afterwards as well of course.)

Dinner

It’s become quite a tradition already that the ladies of Duchess have dinner afterwards, and so seven Duchesses, Diane Etman from VXCompany and two men (since we now allow each woman to bring one male guest) headed off towards ‘de 3 Vrienden’ in the city center. There we met up with the third man, since he had misrembered the time and was already there enjoying the sunshine. VXCompany was very gracious to sponsor the food, so we only had to pay for our drinks. After our first dish we all scooted over three seats so we could talk to more people than just those who were sitting close in the first place. All in all a very successful ending to a great day.

This year’s eclipse forum at Mainz was in cooperation with JAX and SOA. So that sounds great right? If you would purchase the main conference ticket you were allowed to enter all three of them!!! The catch here is that only the Eclipse forum was (almost) entirely in English. JAX was mainly in German and SOA, well I do not know, I was not that interested in it. I was quite surprised because nowhere in the website was mentioned that it would be in German: “3-in-1 Conference Combo: Register for the Eclipse Forum Europe and enjoy the JAX and SOACON conference as well!”. I started getting suspicious only because on the timetable most titles and descriptions were in German… Unfortunately the language barrier limited my options so I had to stick with the Eclipse talks which proved to be quite interesting.

Day 1

The first day started with a talk about the Eclipse Modeling Project (EMP), a top eclipse project that facilitates model driven software engineering. It contains lots of interesting tools for code generation, validation, model querying, database mapping, concurrent access to models etc. Also the EMFT, a project in its incubation stage that aims to extend/complement EMF (the main component of EMP) provides additional functionality such as a query tool more UI oriented, support for the .NET platform, a tool model’s comparisons and a plug-in that enhances eclipse for working with code generation.

Later that day I attended two very fun talks from Ted Neward: Busy developers guide to Scala and the same for ECMAscript. Both talks seemed suitable for developers of none or some knowledge about the particular languages. Scala was definitely one of the hot topics of this conference.

That same afternoon the keynote was ‘Architecting your way through recession: an open source survival kit’. The talk was about recession and open source. As long as I was there, it was mainly about common knowledge stuff with a touch of marketing (the speaker was from one of the conference’s gold sponsors Liferay).

The next talk I visited was called ‘Fresh Ideas for UI – Interaction design in Eclipse’. I went there with a colleague of mine that is really interested in new ideas about UI design, but none of us found them really fresh. We definitely saw some very pretty applications but were mainly comprised of old ideas put nicely together. The presenter was a psychologist that seemed very experienced on user-computer interaction. Even though he gave some good generic tips about UI design, his lack of technical knowledge didn’t help people like my colleague that were interested in eclipse specific information.

During the evening break they were offering beers. When I attended the following talk I found out why.

It was a great keynote by Neal Ford with the strange name ‘Ancient Philosophers & Blowhard Jamborees’. After the talk two phrases got stuck in my mind, the first of which is accidental complexity. It is the tendency of introducing extra complexity on projects and then later having to deal with it. And some of the reasons that he stated sound a bit too familiar: Manager Boards that comprise of people with none or little technical knowledge, meetings that end with the conclusion to reschedule a meeting and software/hardware that has to be used because the company just purchased it at some point, even though it introduces additional complexity. And what he thinks this will lead to if we do not become more aware and active about it? The transfer of most software development to Asia and in particular Chindia. And there is exactly where my second favorite phrase fits shift happens.

Now you understand about the beers…

Day 2

The second day started with a morning talk about ‘what s new in BIRT 2.3‘. Some of the new stuff is the introduction of a JavaScript debugger and improvements on charts and reports. Also two new nice aspects are that each report can now return multiple results sets and that preferences can defer among BIRT projects and not only among workspaces.

Next talk that I was interested in was ‘BIRT within Java Enterprise’. To my disappointment the speaker announced that the presentation was in German because he only found out that it should have been in English the day before… I rushed to a talk about Xtext, a framework to develop external DSLs. The main idea behind it is that one can define a language grammar and then Xtext is responsible generating the parser, the editor etc.

The key note was unfortunately in German. You can find more details about it at my x-colleagues review who happens to be a German speaker. So for me it was time for a break. But what can you do during a break when there is no coffee (they served coffee few times a day, which was disappearing quite fast) and more importantly no Internet? (the coverage was so bad that you could rarely connect…) Oh well at least I could queue early for the lunch which by the way was good and in general the whole conference was very well catered.

Another talk that I attended on that day was ‘Domain-Specific Languages in Groovy’. Also very interesting, DSLs seem to be quite in at the moment. After yet another keynote in German there was an interesting talk by Wayne Beaton where he presented a simple application that runs on a desktop using Eclipse Rich Client Platform (RCP), on a server using Rich Ajax Platform (RAP), and as an embedded application using embedded Rich Client Platform eRCP (see EBERT). Quite tricky actually, since not all platforms have all libraries available, so especially for eRCP the options are quite limited.

Day 3

Thursday started with a talk about user friendly Eclipse applications. They gave some useful tips about what the user wants and they showed that it is pretty straightforward to create cheat sheets, help, info bubbles etc. Following to that, Wayne Beaton presented Eclipse support on top down development with some nice examples. The bottom line would be ‘treat your tests as first class citizens‘.

This afternoon did not differ much from the previous one: a keynote in German, no Internet and me together with few more none German speakers queuing early for lunch.

After lunch I attended a talk by Martin Lipper about general tips on OSGI. A point he made there was that in order to reduce coupling it is preferable to import bundles rather than require them. Also another good point was about extension points; one should not misuse them. For instance if we are not sure who wants to use some particular functionality we should better expose it as a service. Next talk was about the use of OSGI for dynamic application. A demo and discussion can be found at Kai’s blog

Finally the day and conference closed for me with a talk about Equinox p2, the latest provisioning mechanism. Really cool stuff!

The slides from Monday and Friday workshops can be found at:

o www.jax.de/ccm_agile_mon

o www.jax.de/ccm_jsf_fr

o www.jax.de/ccm_osgi_fr

o www.jax.de/ccm_soa_mon

o www.jax.de/ccm_pws_mon

o www.jax.de/ccm_pws_fr

The other slides will not be online but will be posted to attendee’s house individually (which I haven’t received yet). Hmm…

In case you are interested in more information about one of the talks please let me know. I have some notes and I was there with few more colleagues/friends that attended different ones.

About fifteen people, including some men, were present at the IProfs
office in Utrecht for the Portal workshop. After some drinks and a plate
of mexican food we took our laptops to the presentation room. Marco
Beelen is a software architect working for IProfs and even portal exam
leader at JavaBlackBelt, so he has quite some knowledge about portals.
He first explained what portals are, what they are used for and which
portal servers are most used in real life. It appeared WebSphere
is used most, but since JBoss Portal is Open Source and a good second
choice, this portal server was used during the hands on exercises.

We have installed JBoss Portal (extract-and-go) and have created and
deployed our first portlet. We even got two portlets talking to
eachother, fun! The workshop consisted for a large part of practical
exercises which really gave us a feeling of what a portlet server does
and what a portlet really is.
It was an interesting evening and nice to see so many already familiar
faces there again!

Tuesday January the 20th, many Duchesses from several countries traveled to Utrecht to attend the Duchess Agile Event. I was the first non-IProffs employee to arrive. Slowly everybody trickled in. Just past six the catering arrived to bring the food. (Very good Chinese food!) Not everybody was there yet, so we decided to wait a while longer and chatted. Sabrina and Michael had arrived and were honored for coming all the way from Paris. When we could no longer wait for fear of starving, we started the dinner with everybody who had arrived. During dinner the other people trickled in, but unfortunately I was so distracted by my food that I didn’t get to greet everybody properly. *hangs head in shame* Some fine chairman I make. I promise to try and do better next time. I didn’t even get a chance to talk to Angela Sindic from Germany.

After diner we had to get started on the workshop for fear of running out of time. By then everybody had arrived. Michael Franken started off with a presentation about why we need Agile software development. Comparing software development to preparing food. Saying that there are two types of project. One was following a recipe from a cookbook, and the other creating a new recipe. It was rather obvious that software development falls into the second category. (Seeing how the cookbook style is rather like following a tutorial, nice to figure out how certain tools work, but useless to create actual software.)

After this presentation the actual workshop started where we got to try out planning poker. Our tasks weren’t software related, as such tasks would take too much time to complete three iterations in one evening. Instead we had to do sums, fold boats and inflate balloons. The tasks may have been trivial, but planning poker is not. After only three iterations all three teams could accurately estimate how much work they could do in one iteration.

All in all it was a successful workshop and a great evening.

Of course not everything went according to plan, so here are some plans to improve our workshops. Please feel free to chip in with more ideas in the comments.

- Make a planning and communicate it up front.
- Related to the above, mention whether there will be dinner or not.
- Make a list of people who attend and make sure who is actually present (nice way of also making sure to talk to everybody).
- Mention the attendance fee and communicate the bank account number.
- Prepare a proper thank-you speech.
- When planning a raffle, make sure you have time for it. (As I now had to take all the goodies home again.)

On December 10, 2008, Linda and I did a BOF at Devoxx. BOF came from the phrase Birds of a feather flock together. BOFs are perfect for gathering a group of people who care about a certain topic. At our BOF, about 30 women and a few guys gathered to hear about Duchess and to discuss the issues around women in IT. Due to the large volume of research that I wanted to share, we only had a short time for discussion. I would like to recap what we had talked about and perhaps continue the discussion here online. If we were to ever do this in the same format, I would like to keep the talk short to leave more time for discussion, and have a organized meet-up for dinner and drinks where we can continue the discussions in a more informal setting.

Introducing Duchess
First, Linda talked about how we started Duchess and why we, as female Java developers ourselves, would like to see more women as colleagues. As introduction, she told that Duchess is a community of female Java developers with over 100 members world-wide, created to support and promote women in the Java industry. We provide a platform for professional and social networking that allows our members to connect with each other. Our short term goals included organizing social outings, technical sessions, study groups, and discounts for events and courses. After coming back from Devoxx, we finally became a foundation, so we can better arrange our activities for our members. Our long term goals include establishing local branches world-wide, starting outreach programs to reach other women and girls and get them to become passionate about IT. We also need to reach out to existing organizations that promote women in IT to possibly collaborate with them on our similar goals. Here at Duchess, our policy is to make visible the successes and challenges involving women in IT. Hopefully, through our collective passion and effort, we can help to change the image of IT into a great career choice for women.

Encouraging Girls
Someone (please let us know who you are) mentioned the role of parents in showing girls the choices they have by not limiting them. From a US-based education website, I found some practical advice for encouraging girls in maths and sciences. This includes:

• Ability is Expandable – Teach students that the brain grows when they practice and learn new material.
• Prescriptive Feedback – Provide prescriptive, informational feedback on strategies and effort.
• Female Role Models – Show students female role models to counter gender stereotypes.
• Sparking Curiosity – Spark initial curiosity and foster long-term interest in math and science.
• Teaching Spatial Skills – Teach students spatial skills such as how to visualize and manipulate forms and shapes.

As far as I’m concerned, these ideas also apply to software development. Ability is definitely expandable as long as people are curious and willing to learn. Feedback is an essential part of modern development methodologies and are instrumental in motivating people. Female role models show us what is possible in our careers. The ability to think abstractly while being able to produce concrete results is essential to software development.

Women with Passion for IT
Next, a professor who teaches programming in Estonia (again please let us know who you are) mentioned that in her class, the girls are less passionate about programming than the boys and therefore, they are not as good as boys. Perhaps the question here is: Why are they not passionate about IT? This means to me to be a case of self-fulfilling prophecy. If they think they’re not as good, then they’ll be not as good. Although girls on average perform better than boys in math classes at all levels, girls are more likely to feel less confident about their answers on tests and often express doubt about their performance. So, it’s perception issue – self-perception, as well as perception of parents and teachers. Furthermore, stereotypes (even subconscious ones) have a great affect on performance. When girls were told before a test that boys were better in math, their test scores suffered. So, in my humble opinion, confidence is the key to passionate learning because confidence allows one to try new things and this can come from risking and failing in a safe environment. With positive feedback leading to a sense of accomplishment, passion can be built and nurtured.

I did get the feeling that not everyone who had something to say had a chance to speak at the BOF. So, please feel free to comment.

• Part 1: Challenges for Women Entering and Pursuing a Career in IT
• Part 2: Reasons Why More Women Should be in IT
• Part 3: Strategies to Tackle the Issues

• Climbing the Technical Ladder: Obstacles and Solutions for Mid-Level Women in Technology
• The Business Case for Gender Diversity
• The State of Women and Technology Fields Around the World
• Where are the Women in Information Technology?
• Why More Women Should Consider a Career in Computer Programming
• Women wanted in Europe’s ICT industry
• Promoting ICT Among Young Women in Europe
• Women Employed in Science and Technology
• Women Matter: Gender Diversity, a Corporate Performance Driver
• Women holding purse strings
• Best Buy gets in touch with its feminine side
• Men Write Code From Mars, Women Write More Helpful Code From Venus

And of course the title is in relation to this post about the last JFall. Not in relation to JFall itself. Bachelor-ICT made a recap movie and gave us permission to embed it on our site. And since they interviewed me as well (and were kind enough to cut out all the embarrassing stumbling and mumbling), we thought it would be a good idea to do so.

J-Fall 2008 from Bachelor-ict.nl on Vimeo.

As I mentioned in my own blog-post I’am the lucky one who won the free devoxx tickets, Yay! I also wrote in the same post:

I’am a bit behind on the recap though

I made lots of notes and decided to write some posts about the most interesting session I attended, this will include:
XP loops, Seam in Action, Test driven development and PHP on Java.

At University day 1, I attended the session: Scrum in Practice by Chery Sylvain and Yves Hanoulle.
This session was divided in two parts, XP Loops and SCRUM.

You can read my recap about XP Loops here.