Duchess
Globally Connecting Women in Java Technology

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.

There are not enough women in the IT industry, and almost none of them rise to senior management level. The women in the IT company Trifork A/S want to change that.

When Trifork A/S for the 13th time welcomes participants to JAOO Aarhus, female software developers, project managers, IT architects etc. get free access to one of the 3 conference days. A part of the conference programme will be targeted towards those few women who are in the IT industry.

• http://jaoo.dk/aarhus-2009/women/

15% Discount for Duchess members

http://jaoo.dk/conference/

JAOO is a conference for Software Development Professionals organized by experienced software professionals.

Topics covered include Software Engineering, Methods, Tools and Best Practices. JAOO provides a unique indepth technical experience for all participants to learn from and interact personally with world experts throughout the day and evening activities.

The target audience is senior developers, designers, architects, IT project managers and decision makers. The program is focused on a high level technical tracks presented by the leading innovators and technical specialists on the following topics: Architecture, Design, Modeling, Java, .NET, Ruby, Open Source, Agility, SOA and more.

[edit]As I wanted to know for myself I sent an email to the organization to ask them about which days would be conference and which days would be tutorials, and here is their answer:

The conference is Monday-Wednesday (29-30 September and 1 October) Tutorials are Sunday, September 28, Thursday-Friday: 2-3 October.

[/edit]