Resurrected! If you’re reading this, and you have visited my blog before, you are probably noticing changes. My blog was suffering from technical debt for years and I finally dealt with it. When I addressed the technical problems of my blog, I wanted to make something that could last without me putting an effort in. I think this is a useful lesson in software longevity. This blog used to be running on WordPress.

(Technically, this is a blogpost about Oauth2 and not OpenID Connect) Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy? For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere.

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten. Different Identity providers can support different levels of trust between you and your users. In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten. Different Identity providers can support different levels of trust between you and your users. The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master.

Lately I’ve been thinking about how easy it is to fall into the trap of not challenging our ideas about the code we’re working on. In order to challenge the default mindset of Clean Code, I recently proposed to institute Dirty Code Monday (a proposal that sort of got me into a bit of a big discussion). Anyway, here is the report from the first successful Dirty Code Monday one week ago:

I recently did a few days of TDD training for a client. They asked me to help them test and refactor a class that created XML from an internal domain model. This gave me the opportunity to examine a bigger pattern. I wondered where the domain model came from. Looking through the code base, I found that the same or similar data structures were dealt with many places. As often is the case, I also found a bit of code that parsed an XML structure and output the domain model.

My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic. First learn to collaborate The most important skill we should teach is how to work well with others on a shared code base.

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others. Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies.

I’ve long time been a critic of the mechanism of compiler checked exceptions in Java. Whether you love them or hate then, one thing is sure: There’s situations where you don’t want to have to deal with them. The solution in Java is to wrap a checked exception in new RuntimeException(e) but this gives long stack traces without adding useful information. Sometimes, we just want to tell the compiler to chill.

To avoid the big problems with projects, everybody recommends risk management. At the same time, I’ve rarely seen risk management practiced effectively. Do we identify the same risks and do we actually prepare to handle them? The ironic thing is that I think most projects have the same top four risks. In this blogpost, I explore these common risks. To avoid exposing my customers and colleagues, the examples given is based on hearsay and not actual experience.

Recently, my organization reached a big goal and we decided to celebrate by taking everyone out for dinner. What happened was a GDPR nightmare. Or was it? We sent out a Google Form with three simple questions: 1. What’s your name, 2. Are you coming to the dinner? 3. Do you have any dietary constraints? But wait! According to article 4 of the GDPR, “‘personal data’ means any information relating to an identified or identifiable natural person”.

We’re running Mobile Era for the second year on October 5th-6th and I’d like to share some experience on how we’re using scripts and Trello to help with the organization effort. If you’d like automating simple tools, this is the article for you. If you haven’t signed up for Mobile Era yet, you can leave a comment in this blog post for a discount code! Google Forms is great! You can simply design pretty advanced forms and easily get responses.

If you are working with software development as a developer, manager or tester, then you will be impacted by the General Data Protection Regulation (GDPR) – the new EU laws regarding data privacy. In many ways, the regulation is likely to have as big of an impact as the Y2K problem. But this time it’s because of a good cause! And you cannot ignore it, as the fines for doing so can be crippling.

Trailblazing the first delivery of a software system requires courage and conviction, especially on projects that replace existing business critical software. When I’ve been acting as system architect I’ve employed a number of tricks in order to structure functionality and technical solutions in such a way that we can complete these early deliveries without sleepless nights. The most important is to find a subset of functionality that can be used with the rest being completed and investing in bridges from the old to the new.

On the futility of understanding Is true understanding actually possible? I use my fingers to tap out keys on a keyboard and the light from your screen hits our eyeballs, but is it reasonable to think that there is any correspondence between the patterns in my brain and the patterns that were just created in your brain? Or are we just lucky if we have the same thoughts? I used to think that if I just used the right words and asked the right questions and if only those I spoke with responded with the right words, then I would really understand what I needed to know.

So: What is best? A native app or a hybrid app? And if you build a hybrid app, what’s the best framework to use? As with most interesting questions, it turns out that the answer is “it depends”. I often get questions like “isn’t Xamarin (or Cordova) better than build a native app”. Weeeell, it’s not as simple as that. Here’s a few ideas that I’ve found myself repeating lately:

(Looks like I’m back in the conference organization game again! After a few years of lots of travel and then a few years of lots of family responsibilities, this year I co-funded the Mobile Era conference. It looks like it will be a blast!) If your experience is anything like mine, most of the interesting projects around you are having a larger mobile component this year than last year. I think this trend will continue.

As programmers, we have long learned that Duplication is the Ultimate Sin of programming. Even considering to duplicate something is almost unthinkable. But removing duplication introduces dependencies. If you and I use the reuse the same piece of code instead of duplicating it, changes I make may affect you. This effect can anything from beneficial (I fixed a bug you also needed fixing) to benign (I added a new feature that you’re not using) to detrimental (I want it to work in a way that’s no good for you).

I was humbled and encouraged to learn that I was nominated for Nordic Startup Awards category of Developer Hero for my contributions to the developer community. You can vote for me or one of the other great candidates here. For the last ten years, I have felt that the main pain points of the software development world could be fixed by empowering and inspiring those who do the work. From my perspective, I have focused on the developers.

I have an amazing time machine that lets me think better about projects. This is part 3 in a series of blog posts exploring the use of a time machine. In order to get a handle on how to build a feature for your next iteration, take a trip with your time machine to the future to watch how the feature will be demonstrated. It’s often hard for developers to focus on exactly what tasks needs to be performed in order to build a new feature.

I have an amazing time machine that lets me think better about projects. This is part 2 in a series of blog posts exploring the use of a time machine. This is a trick that I learned from my User Experience (UX) friends. In many projects, the project members have a great feeling about the possibilities of the product they are building, even if they quite know if they will get there or if the road ahead will be bumpy.

I have an amazing time machine that lets me think better about projects. This is part 1 in a series of blog posts exploring the use of a time machine. Let’s say that you have a project that has been running for a couple of months. Looking back at your issue tracker and other artifacts, you notice that it’s hard to see what has been done and especially how much time remains.

Do you ever miss a command line to a web application? If you’re lucky, you may use a REST API with appropriate tools for the same job. This Christmas, I bought a Sonos system for our family. It’s a wireless speaker system that uses music streaming services. It supports both Spotify and Deezer, but works better with Deezer and it came with a one year free subscription, so Deezer it is.

JavaScript Promises provide a strong programming model for the future of JavaScript development. So here I’m playing with promises. First I need a bit of a package.json file: { "name": "promises", "scripts": { "test": "node node\_modules/mocha/bin/mocha" }, "devDependencies": { "chai": "^1.10.0", "mocha": "^2.0.1" }, "dependencies": { "q": "^1.1.2" } } Now I can write my first test (test/promises_test.js): var Q = require('q'); var expect = require('chai').expect; describe('promises', function() { it('can be resolved', function(done) { var promise = Q.

The first commandment that any young programmer learns is “Thou Shall Not Duplicate”. Thus instructed, whenever we see something that looks like it may be repeated code, we refactor. We create libraries and frameworks. But removing duplication doesn’t come for free. If I refactor some code so that instead of duplicating some logic in Class A and Class B, these classes share the logic in Class R (for reuse!). Now Classes A and B are indirectly coupled.

Whole frameworks have been written with the purpose of handling the configuration of your application. I prefer a simpler way. If by configuration we mean “everything that is likely to vary between deploys”, it follows that we should try and keep configuration simple. In Java, the simplest option is the humble properties file. The downside of a properties file is that you have to restart your application when you want it to pick up changes.

This summer has been the most significant in my life. While I don’t often write about personal matters in this blog, I will make an exception. On July 12th my son Leon was born. Healthy, happy and obviously, from the perspective a father, perfect. Going through this fundamental life change has made me decide to re-evaluate a lot of things. Most importantly, I wanted to evaluate my career. In the last few years, I have spread my focus thin.

Pop quiz: What will be the output of this little program? public class DateFun { public static void main(String[] args) { long hours = getHoursOfDay(LocalDate.now(), ZoneId.systemDefault()); System.out.println(hours); } private static long getHoursOfDay(LocalDate date, ZoneId zoneId) { ZonedDateTime startOfDay = date.atStartOfDay(zoneId); Duration duration = Duration.between(startOfDay, startOfDay.plusDays(1)); return duration.toHours(); } } The answer is, like with most interesting questions, “it depends”. How can it depend? Well, let try a few examples: getHoursOfDay(LocalDate.of(2014, 7, 15), ZoneId.

This article is dedicated to the ExileOffice team - revolutionizing the way we run our business in Exilesoft. As applications move more and more of their business logic to the client side, it falls upon us to simplify what’s left on the server to avoid distractions. My previous article shows how I get rid of lot of the boring and noisy code. There is one thing that the server will always be responsible for: Security.

I once visited a team that had fifteen layers in their code. That is: If you wanted to display some data in the database in a web page, that data passed through 15 classes in the application. What did these layers do? Oh, nothing much. They just copied data from one object to the next. Or sometimes the “access object layer” would perform a check that objects were valid. Or perhaps the check would be done in the “boundary object layer”.

Working with web applications in NodeJS is great. Using the same language and libraries on the client and server simplified the thinking. And NodeJS has fast tests and restart for a super quick edit-verify cycle when you’re coding. I like to write tests to verify the server-side and client-side logic, but do you know that the whole solution really is working? You can of course test your service manually after deploying, but that becomes tedious.

One of my favorite ways to develop software is to do it together with others. Pair programming has always been a motivating and fun activity for me, but some pairings work better than others. When our team was formed we decided to pair program and rotate partners every day. I had lots of fun programming with Milina, Asanka, Manoj and Chamath, but my favorite session was the one I had with Sankalpa.

If need the same functionality in two projects, you should reuse code between them, right? Or should you? For as long as there has been a profession of software engineering, we have tried to achieve more reuse. But reuse has both a benefit and a cost. Too often, the cost is forgotten. In this article, I examine the economics of reuse. True story: One of the earliest projects to embrace object-oriented programming in the 1990s did so with the goal of maximizing reuse.

I’ve started using an approach for software project estimation that so far is proving to be fairly transparent, quick and reliable. I’ve observed that within a reasonable degree of variation, most teams seems to complete about one “user-relevant task” per developer per calendar week. There are so many theoretical holes in my argument that there’s no point trying to cover them all. The funny thing is that it seems to work fairly well in practice.

This blog post is dedicated to my colleague Seminda who has been experimenting with how to create simple and powerful web applications. Thank you for showing me your ideas and discussing improvements with me, Seminda. I find many C# applications have much unnecessary code. This is especially true as the weight of the business logic of many applications are shifting from the backend to JavaScript code in the web pages. When the job of your application is to provide data to a front-end, it’s important to keep it slim.

In his article Horizontal Reuse: An Alternative to Inheritance Toby Inkster compares how to implement multiple inheritance or mixins in Java, Perl, PHP and Ruby. It’s a very interesting comparison of programming languages features and well worth the read. Toby writes: In class-based object-oriented programming, when there are classes that appear to share some functionality, this is often a time when people will refactor them into two subclasses of a common base class, avoiding repetition.

Less Overproduction (of unused functions in interface between team members) Less Waiting (for the only person who knows a particular area) Less Motion (as everyone gets more skilled) Fewer Defects (because two pair of eyes see better than one) Less Over-processing (from duplicate responsibility) Less Inventory (as team works on focused set of features and tasks) Less Transportation (handoffs inside a story) Less Underused talent (as everyone gets to share their skills)

My post on DZone about Humble Architects sparked somewhat of a controversy, especially around my disparaging comments regarding Spring and Dependency Injection Frameworks. In this post, I expand on why I stopped using Spring. I was one of the earliest adopter of Spring in Norway. We developed a large system where we eventually had to start thinking about things like different mechanisms for reuse of XML configuration. Eventually, this evolved into the @Autowire and component-scan which took away the problem with huge configuration files, but in return reduced the ability to reason about the whole source code - instead isolating developers in a very small island in the application.

I’ve previously talked about the idea of shifting from estimates to budgets. The fundamental point of this article is that it’s more useful to control costs than to predict costs. The problem of this argument is whether it’s possible to develop software in that way. How will the relationship between the developer (or supplier organization) and the customer (or the customer organization) have to change? Is this a chance we’re able to make?

Lean thinking describes seven classical sources of waste 無駄: Overproduction: Making stuff that nobody buys Over-processing: Creating stuff that is more fancy than what the customer wants Transport: Moving stuff from one place to another in order to create it or give it to a customer Motion: Expending unneeded effort while creating stuff Defects: Having to redo work because it wasn’t done right the first time Inventory: Storing stuff waiting to be worked on more Waiting: The time stuff is just sitting there, waiting to be worked on Often an eight is added: Unused talent

Humility is not a very common trait with software architects. After having worked with a few awful architects and recently with a very pleasant one, I’ve compiled a few of my experiences in the way every architect loves: As a set of rules. Rule 0: Don’t assume stupidity It seems like some architects assume that developers, if left to their own devices, would behave like monkeys. In my experience, this is very rarely the case.

XML libraries in Java is a minefield. The amount of code required to manipulate and read XML is staggering, the risk of getting class path problems with different libraries is substantial and the handling of namespaces opens for a lot of confusion and errors. The worst thing is that the situation doesn’t seem to improve. A colleague made me aware of the JOOX library some time back. It’s a very good attempt to patch these problems.

“Show frequently what you’ve done to someone who cares” Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I increasingly hear experienced professionals at Agile conference bemoan the blind adherence to the techniques of Scrum without understanding the principles and values that make it work. I also encounter many software professionals who are overwhelmed by the amount of things that they are asked to do.

I recently read The Git Book. As I went through the Git Internals parts, it struck me how simple and elegant the structure of Git really is. I decided that I just had to create my own little library to work with Git repositories (as you do). I call the result Silly Jgit. In this article, I will be walking through the code. This article is for you if you want to understand Git a bit deeper or perhaps even want to work directly with a Git repository in your favorite programming language.

My colleague and resident Git evangelist Guhan has written a very useful blogpost that gives a Step-by-step guide on how to set up Git clients for Windows. If you’re just now joining a Git project, this is exactly what you want. Read the article on his blog

How to make your code more concise and well-behaved at the same time Have you ever had an application that just behaved plain weird? You know, you click a button and nothing happens. Or the screen all the sudden turns blank. Or the application get into a “strange state” and you have to restart it for things to start working again. If you’ve experienced this, you have probably been the victim of a particular form of defensive programming which I would like to call “paranoid programming”.

In order to smoke test web applications, I like to run-to-end smoke tests that start the web server and drives a web browser to interact with the application. Here is how this may look: public class BookingWebTest { private DataSource dataSource; private Server server; @Before public void createServer() throws Exception { dataSource = DataSources.getTestDataSource(); new EnvEntry("jdbc/applicationDs", dataSource); server = new Server(0); server.setHandler(new WebAppContext("src/main/webapp", "/test")); server.start(); } private final WebDriver browser = new HtmlUnitDriver(); @Test public void shouldShowCreatedBookings() throws Exception { PersonDao personDao = new PersonDao(dataSource); Person person = new Person(); person.

Many sources of stress on projects come from forgetting what our roles are. Scrum championed a simple set of roles with the development team, the Scrum Master, and the Product Owner. The first problem is the people affected by agile projects who fall into any of these categories, many of which are important. The second problem comes from forgetting that the only roles with authority, the Scrum Master and the Product Owner are the least important people on the whole project.

In HTML applications, jQuery has changed the way people thing about view rendering. Instead of an input or a text field in the view pulling data into it, the jQuery code pushes data into the view. How could this look in a server side situation like Java? In this code example, I read an HTML template file from the classpath, set the value of an input field and append more data based on a template (also in the HTML file).

As I’m working with smaller and more agile projects, I’m increasingly seeing the classic way that Scrum is executed as more of an impediment to agility than a helper. This is especially the case when it comes to the classic Sprint Planning as described in [the Scrum Guide](http://www.scrum.org/Portals/0/Documents/Scrum Guides/Scrum_Guide.pdf): “For example, two-week Sprints have four-hour Sprint Planning Meetings” In the Sprint Planning Meeting part 1: “Development Team works to forecast the functionality that will be developed during the Sprint.

During the recent panel debate in Colombo Agile Meetup my colleague Lasantha Bandara asked the following question: How do you start an agile project and ensure room for future enhancements? How can we achieve flexibity at the beginning? This is my answer: Flexibility is about having an acceptable cost of change. Sometimes, the best cost of change is to create something and throw it away early to try something else if it doesn’t work out.

There are only so many ways to test that your persistence layer is implemented correctly or that you’re using an ORM correctly. Here’s my canonical tests for a repository (Java-version): import static org.fest.assertions.api.Assertions.*; public class PersonRepositoryTest { private PersonRepository repository; // TODO < == you must initialize this @Test public void shouldSaveAllProperties() { Person person = samplePerson(); repository.save(person); // TODO: Make sure your repository flushes! assertThat(repository.find(person.getId()) .isNotSameAs(person) .isEqualTo(person) .isEqualsToByComparingFields(person); } @Test public void shouldFindByCaseInsensitiveSubstringOfName() { Person matching = samplePerson(); Person nonMatching = samplePerson(); matching.

Two of my favorite libraries in C#: FluentAssertions and NUnit (of course). NUnit has a “hidden” gem (that is, it’s well documented, yet few developers use it): [TestCase]. Look at this: using FluentAssertions; using NUnit.Framework; public class RomanNumeralsTest { [TestCase(3333, "MMMCCCXXXIII")] [TestCase(555, "DLV")] [TestCase(999, "CMXCIX")] [TestCase(444, "CDXLIV")] public void ItConvertsNumbersToRomanNumerals(int number, string roman) { ToRoman(number).Should().Be(roman); } } The [TestCase] lets us easily have several test cases implemented by the same method.

After having worked with Scrum for a number of years, I still witness sprint reviews where the team’s demonstration of the product is confusing and the value produced in the sprint is unclear. The demo may consist of just a bunch of different functions and screens without any meaning. Or maybe the team is just talking about what happens behind the curtains in the database. Or maybe the demo just doesn’t display the value that the team was supposed to give to the stakeholders.

When I learned math in elementary school, I would reach for my calculator. But my father stopped me: “You only get to use the calculator when you can do math without it.” As you can imagine, at the time I though this was unfair and unreasonable, but later I have discovered what advantage it is to understand the basics before you reach for a powerful tool. Many developers are focused on what fancy framework they will learn next.

When a software architect gets a good idea or learns something new, he has a problem. The main job of the architect is to ensure that the right information in present inside the heads of the people who should build the application. Every new piece of information in the architect’s head represents a broader gap between his brain and that of the rest of the team. The classical ways of adressing this gap is for the architect to write huge documents or sets of wiki pages.

Do you ever feel it’s hard to get real progress in a sprint towards the business goal? Do you feel the feedback from a iteration picks on all the details you didn’t mean to cover this sprint? Do you feel like sprint planning meetings are dragging out? Then a Rainbow Sprint Plan may be for you. Here is an example of a Rainbow Sprint plan: A customer wants cheap vacations The customer signs up for daily or weekly notifications of special flight offers Periodically the System checks which customers should get notifications The System checks for offers that matches the customer’s travel preference by looking up flights with the travel provider system The System notifies customer of any matching offers via SMS Variation: The System notifies customer of any matching offers via email The customer accepts the offer via SMS The System books the tickets on behalf of the customer The system confirms the booking by sending an SMS to the customer The customer can at any point see their active offers and accepted offers on the system website The customer enjoys a cheap vacation!

Sometimes, small questions lead to big answers. Sometimes these answers are controversial. One such question is “What does this warning about serialVersionUID mean”? All the advice out there basically is for developers who don’t know what’s going on to write code that will ignore errors when something unexpected happens. In my view - this is exactly the wrong approach. The safe way to act is to make sure that your program crashes if you don’t have control.

I have tried to create a simple process for debriefing workshops. This is the current process I use, and I think it may be useful for others. I give everyone sticky notes with three colors I ask everyone to write “a thing that surprised you about the workshop”, “a thing that you learned today” and “a thing that you plan to do as a result of the workshop”. Each question goes on a different color sticky note.

We were taught to categorize, but we know that searching beats sorting We were taught that information is scare, but we know that the real problem is too much information, not too little. We were taught that information must be protected from being viewed, but we know that the greatest threat to information is irrelevancy We were taught to estimate and plan what the marked wants, but we know that our customers don’t behave according to our plans We were taught to guide our customers, but we know they want to serve themselves.

I’m working on this idea, and I don’t know if it appeals to you guys. I’d like your input on whether this is something to explore further. Here’s the deal: I’ve encountered teams who, when working with SOA technologies have been dragged into the mud by the sheer complexity of their tools. I’ve only seen this in Java, but I’ve heard from some C# developers that they recognize the phenomenon there as well.

Changing your perspective even a small amount can have profound effects on how you approach your system. Let’s say you’re writing a web application in Java. In the system you deal with orders, customers and products. As a web application, your classes include staples like PersonController, PersonRepository, CustomerController and OrderService. How do you organize your classes into packages? There are two fundamental ways to structure your packages. Either you can focus on the logical tiers, like com.

An “Agile” project is one that actively seeks to incorporate changes as the project progresses, rather than assuming that the plans from the beginning of the project will work for the whole project duration. Not all organizations want to adopt “agile” as their project metaphor. And some organizations that do adopt methods such as Scrum do it without becoming as “agile” as Scrum promises. Instead of criticizing these organizations of “agile heresy”, I would instead like to offer some useful experience from Scrum, even if the word “agile” doesn’t appeal to you.

I hate giving promises for things I can’t control. I can promise that I will attend a party or that I will set aside time to help you with your problem. I cannot promise that the party will be fun or that your problem will be solved. Giving promises on effort is honest, giving promises on outcomes is dishonest. A team that commits to an estimate is promising something they cannot control.

As a user, I can add social security number, so patient logs have social security numbers As a developer, how would you react if you were given this user story? Would you throw it back in the face of the product owner, or would you try and understand it? How about the following dialogue? Developer: “What are we hoping to achieve with this story?” Customer: “We hope that the patient logs will have social security numbers.

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job. Java web+database applications are usually filled to the brim with technologies.

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo. This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

Instead of using Scrum, maybe we should use MyScrum. It’s like Scrum, with the stuff added that you think will super charge your MyScrum. This is my MyScrum: I want to measure velocity every week I want to demostrate the product with a cadence that makes sure users show up to the demo I don’t want to have story point estimates, I want to have story point budgets I want the product owner, not the team, to own the budget/estimate (but they team may veto) I don’t want commitments or forecasts from the team, I want measured historical progress I want to plan per story, not per sprint I want the developers who will develop a story to follow it (or pass the baton to other developers) from detailing to deployment.

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now? To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen. The quick analysis Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Oracle released Java 7 on July 28, 2011. This is nearly 5 years after the release of Java 6 in December 2006. The release received a lot of bad press, both because it is very meager on features, and because it shipped with a severe bug. Nevertheless, once the most serious bugs have been fixed, you might think about starting to use Java 7. What will this mean? New language features Java 7 has a few new language features.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over.

For those of you who already use PuTTY: Here’s a little improvement that’s surprisingly little known. Probably because it is very hard to explain. But I’ll try. Here is how you can avoid starting programs, entering login information or indeed typing passwords when you use PuTTY: Download Putty installer from the PuTTY Download Page. Make sure to grab the “Installer” Install Putty Start PuttyGen from Start -> PuTTY-> PuttyGen Generate a new key and save it as a .

This blog post is a summary of my lightning talk at XP2011 I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box.

Can the various European Agile User Groups benefit from working together? I am cautiously optimistic. At XP2011 this week, Jurgen Appelo has taken the initiative to launch the Agile Lean Europe network. This is an initiative to bring together representatives from 17 European countries. Sergey Dmitriev and I will be representing Norway. To what end? I’m still not sure. There is no doubt that there is much Europeans can learn from each other.

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement” What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool. Skill If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it.

Teams gather around task boards to plan their day. If the conversation and the task board match, we stay on topic and we understand what the rest of the team talks about. The last month, my project has redesigned the task board with this in mind. Here is a picture of our task board as it looked a few weeks ago: Each column represents a day. The top swimline represents testing tasks, the second swim line represents development tasks, and the bottom represents outside influences.

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better. Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board.

I’m getting a little fed up with descriptions of project development lifecycles starting with waterfall, and then describing iterative and agile development in waterfall terms. What happens if we start on the other side? Project development lifecycles Agile: The project creates a roadmap for a year or two, commits to the scope a delivery in a few weeks to a few months, adapts their commitment as they learn more and irons out the details of each task just prior to when it’s performed.

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge. We practice pair programming to get redundancy.

When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming. Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied.

“Refactoring” is the practice of “improving the design of existing code without changing its behavior”. It’s an essential part of software maintenance. Done well, refactoring will make sure your code base is easy to maintain. Done poorly, refactoring will lead you into a dangerous swamp where you’ll be stuck forever. Good: In order to really get the benefit from refactoring, I think we have to do it all the time. I resolve to always leave a code file in a state where I could be satisfied if I never got to improve it in the future.

Or: Poor man’s dependency injection: Singleton-initialized field As dependency injection frameworks like Spring have become central in software applications in the last few years, the conventional view is now that the Singleton pattern is evil and should never be used. Instead, relationships between objects in your system should be managed by a dependency injection container. I have started disliking the consequence of this strategy very much: All coupling in my system becomes implicit and harder to understand.

The more I code, the more I’ve learned to appreciate keeping the code clean even during complex refactorings. By “clean”, I mean that the code always compiles and the test always run. I often find myself in a situation where I have a method call that’s starting to accumulate parameters. Something like this: showPersonCreateForm(writer, firstName, firstNameErrorMessage, lastName, lastNameErrorMessage,....); After three or four parameters, the need to refactor is starting to become evident.

I though I’d do something different this time. Instead of describing something technical, I have recorded a five minute video that shows a very neat trick in Java: How to create a bit of code that wraps existing method calls to an object with any behavior you may desire. This is nothing new, but I’ve noticed that not many developers know how to use it, so I hope this video may be useful:

As an architect for a team with a large number of people, I have a couple of problems: I often make decisions that turns out to be quite crappy. Even when I think I’ve written or drawn something that’s smart, it often turns out that it’s incomprehensible to everyone else Luckily, I’ve noticed that most developers have characteristics that almost always counter these weaknesses: Most developers are pretty smart, especially when they’re trying to solve a specific problem.

What if you had to report daily your progress on the tasks you’re programming in your project. Wait, you say: “I already do that in my daily standup meetings”. But if your standup meeting is anything like most standup meetings out there, you’ve got a serious blind spot. What if I said that writing code doesn’t constitute progress. Code is effort, not value. In order to demonstrate value, you have to be able to show your progress to someone who doesn’t care about code.

Ctrl-1 is the magic “do what I think” button in Eclipse. Whenever I press it, Eclipse seems to come up with something that’s helpful in the current context. In this blog post, I illustrate 10 things that Eclipse hide under the ctrl-1 keypress. This is a follow up on my post on Eclipse stenography. I got some comments on my last post about Eclipse stenography about the animated gifs. I know this can be annoying, but I considered the alternative: To have you mouse-over or click a picture to animate it.

When working on replacement projects, I often find I need to make minor changes to an existing database that is still in use by one of several other applications. Initially, it may seem like situation will force you to conform to the current database schema. But there are other options, even though they may not be for those who are faint of heart. The general pattern when you want to evolve a database that is in use by legacy system, is to make sure that the legacy system sees the same data structure when it reads from or writes to the database.

Sometimes I’m asked to write or speak about something with very little preparation. In these situations, I need a tool that can help me: Organize my thoughts quickly Prioritize the wheat before the chaff Maintain a coherent train of thought I find a very useful structure for archiving this to be what I call “three-by-three”: Three main points with three subpoints each. Forcing myself to keep to a structure will make my thoughts flow more quickly.

Pair programming and test-driven development are some of the practices that are most often talked about and least often actually understood. So I’ve decided to undertake the task to teach myself to program a simple, yet realistic problem with a pair programming partner. The goal is to create an entertaining and realistic performance that portrays what it feels like to work like this. I’ve been extremely lucky. I’ve found not one, but two programmers that have been willing to train enough with me to make a smooth performance of a pair programming session.

According to Wikipedia, stenography or shorthand is “is an abbreviated symbolic writing method that increases speed or brevity of writing as compared to a normal method of writing a language”. Just as a stenographer learns to take down information really fast, a good programmer can learn to write code really fast by taking advantage of his or her tools. In this post I’ll show you my secret code stenography tricks.

Everyone has heard horror stories about pointy-haired-bosses counting lines of source code to track the progress of a project. We roll our eyes and laugh at their stupidity. But before you laugh too much, you might want to find out whether you’re really any better. Most of what software projects measure are not things we care about. Not things we really care about. Do you really care about the number of coding standard violations in your code?

How many steps do you need to perform to release a new version of your software? Do you even know? Releasing frequently requires the release process to be as streamlined as possible. A good way to get started is to write a step-by-step instruction that explicitly state everything that needs be performed for an installation or upgrade. Then get to work cleaning it up: Make sure you can build and package everything that’s needed for the installation with a single command Does the installation or upgrade require several files to be installed?

No computer system is an island. At least not these days. This creates a challenge when you want to change APIs: Do you want to upgrade all affected systems at once, or do you want to support multiple versions? Both approaches have downsides. Coordinating several upgrades increase the risk that one of the upgrades fail, in which case, you may want to roll everything back. In some situations, rollback may not even be possible.

At JavaZone 2010 I will be giving a lightning talk on APIs that use dynamic subclasses. These APIs make it possible to do things in Java that seem like pure magic. Here are some ideas of what you can get from these APIs and a look under the hood, so you really understand what’s going on. Mockito - “the best Java library named after a summery drink” Mocking is a hotly debated subject within testing camps.

This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you. By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

When picking iteration length for an agile project, there are mainly two forces that you have to balance: The rate of learning is proportional with the number of iterations, rather than the length of the project. This means that shorter iterations help you get better faster. But each iteration has some overhead with sprint reviews, retrospectives and planning. You don’t want this overhead to dominate the effort spent on the project.

If you wonder why this blog has been so quiet lately, it not (just) that I’m getting lazier. Together with several of my colleagues at Steria Norway, I’ve started up a blog at http://sterkblanding.no. “Sterk blanding” is Norwegian for “potent mix”, and we hope that as representatives for several disciplines, we will be able to give a broad perspective on IT and management issues. I’ve not yet decided what posts to publish here and what posts to publish on Sterk Blanding.

I’ve pair programmed the Java EE spike kata in Eclipse with a number of people, I’ve found that a number of keyboard short cuts and preference settings recur as useful new information. I’ve compiled the most popular ones in this article. The article is subject to change, but I won’t change the number of shortcuts. Top five shortcuts There are some keyboard short cuts that everyone who uses Eclipse should know:

As it turns out, one of the least used practices of agile development is also one of the most powerful. Up into the start of last year, I only worked sporadically with pair programming. Last year, I was lucky enough to be part of a team that used pair programming all the time. Since I’ve experienced real pair programming, I never want to give it up. Pair programming offers benefits to many stakeholders:

After seeing some of the great examples of coders working on practiced problems on KataCasts, I decided to try make my own. I am not happy with the pacing of the video. I’m about a minute too early relative to the music. But I thought I’d post the video here, to see what you all think. Comments are welcome! I hope the video will demonstrate how to use refactoring effectively to drive the design of a program.

Lately, I’ve been working on two code katas, that is, programming exercises that I repeat until the motions are secure in my muscle memory. The katas I’ve chosen are: Java EE Spike: An application that stores People with names to a database and lets me search for them. I’ve repeated this pair programming with several different programmers. Programmable Fizz Buzz: Create a sequence of numbers 1,2,fizz,4,buzz,fizz,… you know the one. And the twist: Make it programmable, so that for example numbers divisible by 7 should be replaced with “coconut”.

Lately I’ve been thinking a lot about how easy it is to lose sight of the goal of the project and instead focus on whatever means someone first thought was a good starting point when the project was first conceived of. And I think it all comes down to words. The first years I was working in this business, I didn’t see any distinction between “the user” and “the customer”. Once I started seeing the distinction, I started to understand that the person who is going to use the system we’re developing is not the person who defines what the system should do and neither of these is usually the person that pays me to develop the system.

At ØreDev I ran into Lasse Koskela. We started talking about estimation techniques, and we both felt that the dominant estimation technique of relative estimation with planning poker has been unchallenged for a very long time. We found ourselves wondering what the next big idea about estimation will be. After throwing a couple of ideas back and forth, we decided to invite to a workshop comparing a few estimation techniques. We decided to call the workshop “The Malmö Experiment.

Just three weeks ago, I was asked to step in for Ted Neward to give a tutorial at Øredev on Effective Enterprise Java. As I did not have time to get the tutorial materials printed, I present them here on the web for the participants and others. 1. Effect Enterprise Java architecture in 2009 Since the Effective Enterprise Java book was written, many of the topics regarding transactions, concurrency and shared state have been resolved.

When I write Java-projects that produce web pages, I test on several levels. First, I use Jetty and WebDriver to test the result via http. (WebDriver even lets me test JavaScript!) But for speed and agility, unit-level tests beat even the fastest integration level tests. Unit tests run much much faster, and lets me pinpoint problems much more accurately. As a general rule: If you introduce a bug, you want a unit test to be the one that sees it first.

I’m working on a collection of patterns for early releases with Niklas Bjørnerstedt. Here are some of my thoughts based on this work. In a few different projects, I’ve noticed that the idea of “where are we going” seems to go though a familiar pattern: “The old system is the requirement document, just make the new one do the same things”. After a while, someone will realize that it’s rather pointless to replace a system with a new one that does the same thing, which leads to… “Analyze the business processes and make the new system automate all decisions that a human used to make.

Every Scrum-team should use their taskboard to support their particular way of working. I’d like to share the way we use our taskboard at my current project for your inspiration. [caption id=“attachment_447” width=“300” caption=“Colored ink, paper and makers support team process”][/caption] When I started my current project I went to pick up sticky notes and marker pens for the taskboard. I grabbed, more or less at random three colors of notes (red, green, yellow), four colors of pens (black, red, blue, green) and five color sticky bookmarks (yellow, green, blue, orange, red).

The generation that has been growing up was raised in a world that was radically different from the world we live in now. There is a generational shift, and we know that what we were taught is no longer true: [caption id="" align=“alignright” width=“200” caption=“What does your brain look like?”][/caption] We were taught to trust information from authorative sources, but we’ve learned to prefer the voices of named individuals. Be personal.

What will the daily experience of software development look like, say, five years from now? Have our current processes reached their peak, or will the world continue to change? Alan Kay said “the easiest way to predict the future is to invent it.” Here are some ideas of the future I want to invent: I hope it will be dramatically better than what we currently do. [caption id="" align=“alignright” width=“240” caption=“Steel pipes (by monkeyc.

It’s not secret that Apple likes to control their platform tightly. As long as their dictatorship is a benevolent one, whether you find this objectionable or not is a rather uninteresting question. But lately, the question seems to be less and less academic: Google’s Voice Application for the iPhone got rejected and two existing applications (GV Mobile and Voicecentral) were removed from the AppStore! This is an extremely nasty thing to do to the developers.

In my current project, we use Flex as the user interface framework of choice. Flex has some nice features, but it takes a long time to build changes and start up, so it takes a while to validate our changes. Yesterday, we found a problem with one our UI components, and used JUnit to hunt down the same problem all over our code. The problem was with tables. We had a table where we had set the percentage width of each column, but the total did not add up to 100%.

Why do all societies we know of practice some form of religion? Either religion must be “true”, or there must be some sort of natural explanation for this universal phenomenon. [caption id=“attachment_403” align=“alignright” width=“161” caption=“Breaking the Spell”][/caption] “Breaking the Spell” by Daniel Dennett presents avenues of research into these explanation. He does not profess to have the answers to this question, or even the right question. He merely sets out to prove that the questions are important ones and ones that we can hope to gain insight into.

[caption id=“attachment_394” align=“alignright” width=“300” caption=“Summer is starting”][/caption] “Predictably Irrational” is a perfect book for lazy summer days on the beach or, in this case, while enjoying a beer from top of Oslo’s tallest office building. Dan Ariely is on a bit of a crusade against traditional economics, with it’s idea of rational behavior from everyone in the marketplace.

After receiving request to revive my book reviews, I’ve decided to blog about books I read again. If a known terrorist in police custody knew the whereabouts of a ticking bomb about to explode in a large city, would the use of torture be acceptable? Would it be helpful? I stumbled across Alfred McCoy through fora.tv. The program impressed me so much that I decided to pick up his book A Question of Torture.

I thought it was about time I wrote about topics where I’m an amateur. This time: Experimental philosophy. As a computer programmer, I often entertain myself with writing computer programs. Last Easter I stayed up a few nights playing with an insignificant, but entertaining program. During a discussion with my philosopher uncle, I discovered that this program might provide some insight as to why determinism is, if not dead, then at least lame.

Here’s a neat trick if you want set an object in a specific state in a unit test, but you don’t want to violate encapsulation: @Test public void withdrawShouldReduceBalance() { Account account = new Account() {{ super.balance = 100; }}; account.withdraw(10); assertEquals(90, account.getBalance()); } @Test(expected=IllegalStateException.class) public void overdraftShouldThrow() { Account account = new Account() {{ super.balance = 5; }}; account.withdraw(10); } This seemingly magic code lets me have a protected (but sadly not private) field Account#balance.

The Agency for Public Management and eGovernment in Norway is currently developing guidelines for IT-projects within the Norwegian governmental sector. The Norwegian Computing Association hosted a presentation and discussion about this work yesterday. I was privileged enough to summarize the comments from one of the three discussion groups at the meeting. For the enjoyment of the internet, I hereby provide a few ideas on eGovernment projects. Value first The speaker from The Norwegian Government Agency for Financial Management (SSØ) pointed out that many projects are not sufficiently concerned with satisfying real objectives.

In this third podcast in the Oslo Developer Conversation series, I talk with Linda Rising about fearless change. We discuss the how to inspire an organization to change and touch on how developers are, at the end of the day, just another mammal. See the (English language) podcast at ProgramUtvikling’s site.

The last couple of months have been full speed and not much time to reflect and write. The fact that we’re pair programming on the team gives me less time to think about great blog subjects. As an architect, it’s hard to find enough time to complete a meaningful unit of work without doing the dreaded “architect-commit-and-run” move. However, I found that when I have time to program, the pair programming culture on our team works really well.

In this second podcast in the Oslo Developer Conversation series, I talk with Robert Martin about FitNesse. We discuss the origins of FitNesse and it’s relationship with Fit, the relationship between acceptance tests in FitNesse and unit tests and the new Slim-tables in FitNesse. See the (English language) podcast at ProgramUtvikling’s site. Comments: jhannes - May 26, 2009 In the PodCast, Bob mentions Parnas tables as an inspiration for FitNesse table structures.

This is a test case from my current project: Scenario: Finish gathering information Given I have an open case And the case has a task "gather information from X" And the case has a task "gather information from Y" When the user confirms that task "gather information from X" is completed And the user confirms that task "gather information from Y" is completed Then the case should generate a new task "evaluate customer standing" It seems pretty run of the mill.

Doing the Code Dojo at Oslo XP meetup last Monday, I realized a new concept that I’ve been using unconsciously for a while: I only add to the structure of my system when I have a test that cannot be satisfied by the current design. The rules of test-driven development tells me to wait to create a more advanced design until I have a reason to do so. And that reason should be a failing test.

Agile development is easy to understand and hard to do. One of the hardest things to do is to base plans and actions on value instead of effort. An article by Alistair Cockburn includes a story that illustrates the point: A boy is behind on his German language home work. He now has to read ten stories and answer a set of question for each. He will be graded on the number of correct answers.

My friends at ProgramUtvikling just published the first PodCast in the series Oslo Developer Conversations. In this PodCast, yours truly interviews Uncle Bob about software craftsmanship. The podcast is still only available as video, but audio will come shortly. I had a great time doing this interview and I’m particularly happy that we managed to have a good combination of a technical discussion and an informal discussion. I’m looking forward to doing lots more of these in the future.

I’ve all but stopped using mock objects in my tests. The reason is that mocking have had a detrimental effect on the design of my systems. I’ve often ended up having the mocks trick me into adding a needless layer of indirection that does nothing except delegate to the next layer, just to satisfy the mocks. For a while, I was wondering whether I was the only one with this problem, but then I saw this tutorial on JBehave, which so perfectly illustrates the problem I saw myself doing.

The hard choice between duplication, paralysis and chaos A common programmer credo is “Don’t Repeat Yourself” (Pragmatic Programmer) or “Once and only once” (Extreme Programming). Like all credos, we risk following it even when it is not appropriate. The larger truth is that we have choice between three evils: We can duplicate our code, thus duplicating effort, understanding and being forced to hunt down twice. We can share code and affect everyone who shares the code every time we change to code to better fit our needs.

The following is a trick I don’t use very often, but when I do need it, it comes in very handy. It’s a trick that many developers aren’t aware of, even though it’s been possible to do with JUnit at least since version 3. Sometimes you want to have a lot of tests that are almost the same, but that contain different arguments. For example, for a yahtzee calculator, you might want to have the following tests:

If you ever talk to a group of people, you know that the art of presentation is one that requires a lifetime to master. But there are some dirt simple things you can do that will have a positive impact on your presentations. Here is my list of low hanging fruit for presenters: If you’re using a computer, use a presentation remote. This is a cheap and easy way to make your presentation style look a little more professional.

[caption id="" align=“alignleft” width=“165” caption=“Unstructured picture”][/caption] I recently started on a new project. Looking over the code base, I saw the familiar structure of many projects: Definitions of classes goes here, persistence logic goes over there, interfaces to the persistence logic goes this other place, code for transforming from one structure to another in yet another place and so on. This is common, neat, and unfortunate. As an exercise to understand the architecture of this system, I decided to add some new functionality: Displaying some data to the user.

“The service went down because another service running on the same application server went down.” “You can’t use the improved version of your programming language because you’re running on the same application server as some old applications.” “We can’t help you deploy your application on the application server, because we’re busy with some other application.” If you’ve ever heard any of these statements, you’ve been victim to the accidental complexity of the application server.

Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: “You know, I really should do something about that… but I don’t have time just now”? On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it? When I start a new project from scratch, there are no warnings, no clutter, no problems.

Top five signs that you might not be working on an agile project: Your iterations do not produce anything that could be put into production You’re not testing your work You tasks are called “code the UI for the foo”, “update the bar component” and “test the work done in the previous iteration” Your iterations are called “specification”, “testing”, and “preproduction” And the top sign that you might not be working on an agile project: You might not be working on an agile project if your iterations are three months long Happy Holidays, Merry Christmas and Happy Monkey, everybody.

I became a programmer so that I could spend time creating software by programming. I don’t want to waste my time managing low-quality code. Does your code work the first time your test it out? Mine certainly never does. So if I hand over the code to someone else, I’m sure to get a bug report back that will take up my valuable programming time. This much is obvious to most developers.

Agile software development has learned about informative workplaces and stop-the-line quality management from lean manufacturing systems. Here are my implementations of it at my last project: All is well This video shows how our project looked when all is well. The large green light in the front shows the status of our build server. The green flashing lights show the status of our staging and production server. For the production server, the frequency of green blinks indicates the load of the system for the last 10 minutes relative in % to highest load ever observed.

Update Thanks to Alan Palmer for this trick that makes this whole post unnecessary: If you use !path {java.class.path} You get the classpath that fitnesse was called with, without the need for changing the fitnesse code. Regular readers of my blog may remember that I’ve researched how to get the classpath from the FitNesse-process inherited by the Fit process that FitNesse spawns when it runs a test. This trick is an easy way to get around having to specify classpath variables in your FitNesse tests.

This article is a repost of my comments to the question on how to implement hashCode and equals on stackoverflow There are some issues worth noticing if you’re implementing hashCode and equals for classes that are persisted using an Object-Relationship Mapper (ORM) like Hibernate. If you didn’t think this topic is stupidly overcomplicated already! Lazy loaded objects are subclasses If your objects are persisted using an ORM, in many cases you will be dealing with dynamic proxies to avoid loading object too early from the data store.

When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I’m talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging is as useless as none at all.

Attributes. Keeps getting better ’n better. Check out Extensible C#, Clemens Vasters new demos, and the underutilized ContextBoundObject ADO.NET. The ADO.NET model for modeling and transporting data hits right on the spot. Better FFI. P/Invoke wins against JNI, hands down (too bad it is probably overused, though) Not EJBs! Getting rid of the defunct EJB model saves a lot of headaches. Better UI. For the user, that is, not the developer!

Open Source Community. The number of excellent open-source tools for Java is staggering. Look at HSqlDb, BeanShell, Eclipse, Recoder, JGraph, Tomcat, JBoss, and many more. More importantly, the Java community has proven much more interested in doing it the open-source way. Eclipse. Already mentioned, but it deserves a point of its own. Eclipse is a better IDE than VS.NET! Checked Exceptions. Less Native Code & more code reliability. .NET still has some weird crashes.