This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October. Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til. Vi har lært en del ting om hva som i teorien skal være løsning:

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.

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:

Er det noen som sammenligner omfang og kostnad på IT prosjekter i Norge? Jeg tror man kunne få noen interessante innsikter dersom man gjorde dette riktig. (Jeg må unnskylde at teksten i denne blogposten blir litt vag - jeg ønsker å si så lite som mulig om de aktuelle prosjektene for å unngå å eksponere andre) Akkurat når jeg var involvert i et tilbudsarbeid for et prosjekt, var jeg samtidig involert i den endelige godkjenningen av et annet prosjekt.

Man kan lese fra moderne tanker på IT-utvikling at prosjekter er en avleggs arbeidsform. For de som har erfaring med utviklingsaktiviteter innen offentlig og privat sektor kan dette virke som en rar påstand. De aller fleste ser behovet for å unngå store prosjekter, men er prosjektet som arbeidsform virkelig avleggs? Det spør naturligvis på hva man mener: I alle de årene jeg har jobbet med IT-utvikling er det en ting som er sikkert.

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 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.

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.

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.

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.

“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.

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

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.

“Problemet med Java er at det krever så mange abstraksjoner. Factories, proxies, rammeverk…” Min samtalepartner gjenfortalte inntrykket han hadde av de Java-programmerende kollegene sine. Jeg måtte innrømme at jeg kjente meg igjen. Kulturen rundt Java-programmering har noen sykdomstrekk. Kanskje det minst flatterende er fascinasjonen for komplekse teknologiske løsninger. Et gjennomsnittlig Java-prosjekt har rammeverk (Spring, Hibernate), tjenestebusser - gjerne flere (OSB, Camel, Mule), byggverktøy (Maven, Ant, Gradle), persisteringsverktøy (JPA, Hibernate), kodegeneratorer (JAXB, JAX-WS), meldingskøer (JMS), webrammeverk (JSF, Wicket, Spring-MVC) og applikasjonsservere (WebSphere, WebLogic, JBoss).

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.

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.

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 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!

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.

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.

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?

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.

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.

I’ve published a Norwegian language article titled: “Min supre produkteier” (“My excellent product owner”) at the company blog for Steria Norway. Go check it out if you understand Norwegian!

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’ve published a Norwegian language article titled: “Slik lykkes du med smidig utvikling” (“How to succeed with agile development”) at the company blog for Steria Norway. Go check it out if you understand Norwegian!

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.

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.

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?

As I release more frequently, I start to focus on automating the actual process of deploying a release. One of the most powerful steps of automating deployment is to automatically upgrade the database schema. This technique first saw mainstream use with the Ruby-on-Rails framework. Today, there are several mature tools that will help you organize and execute database changes (Scala Migrations, Ruby-on-Rails Migrations, dbdeploy, Liquibase, dbmaintain). And if none fit you perfectly, it’s easy to create your own.

A software architect who doesn’t care about what his system is supposed to do isn’t worth his salt. For the term “software architect” to hold any meaning at all, it must be to describe someone who understands what the customer needs and designs a system that is fit for this purpose. Sometimes, however, people talk about “technical architects”. I have myself been guilty of falling into this category once or twice myself.

If you want to release frequently, a problem you may encounter is that some features, even though functionally complete, don’t stand well on their own, but require other features to be valuable to the user. If you want to release the system in this state, you need a way to hide features. A Feature-on/off-switch is a simple idea for dealing with this. A feature-on/off-switch is some mechanism to hide features from a system.

As a general observation, it seems that when software architects try to solve general problems, they come up with horrible designs; when they solve specific problems, they come up with good designs. Designs made without reference to a problem often become complex and not very fit for purpose when we’re solving specific problems. As a general rule, avoid generalizations. Some examples: An Enterprise Service Bus may create a big project and maintainable needs for something that turns out to be only a few simple integration points.

When developing a system that people use in their day to day work, I often meet the following requirement: “A user should be able to see all tasks from each functional area on a single screen.” This requirement requires integration with all parts of the system, making it architecturally costly. Luckily, the requirement might often not be needed at all! Everyone will tell you: The most powerful technique for dealing with a large problem is breaking it up in smaller problems.

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.

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:

For å bli bedre må man trene. For å bli bedre med avanserte ting, må man forstå de grunnleggende tingene bra. For å vite hvorfor man bruker avanserte verktøy, må man prøve å jobbe uten dem. Derfor har jeg de siste ukene trent mange ganger på å lage en veldig enkel webapplikasjon i Java. For hele applikasjonen har jeg startet med å skrive testene før koden som implementerer funksjonaliteten. Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang.

En kollega spurte i dag om mine topp tips når det gjelder databaserefactorings. Her var mitt svar: Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite) Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren.

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.

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.

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it. I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”. [caption id="" align=“alignnone” width=“360” caption=“Dette er Scrum”][/caption] 3-minutterguidene kan lastes ned fra Sterias hjemmesider. Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum.

This Norwegian language post talks a little about a quick intro to Scrum that I wrote for my employer Jeg har forfattet en “3-minutters guide” til Scrum. Dette er en to siders lettlest artikkel som publiserer via min arbeidsgiver Steria. Denne har som mål å være tilgjengelig både for tekniske og ikke-tekniske prosjektdeltagere som gjerne vil forstå litt mer om hva Scrum dreier seg om. Du finner artikkelen på Sterias arkiv over 3-minuttersguider.

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.

This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling.

This blogpost is a Norwegian language tribute to one of my home city’s great poets Med takk til Joachim Nielsen Ta en titt inn på skjermen din æ’kke testen grønn Det var mye værre her om da’n da var alle tester røde Skulle vært her i forrige uke, da hadde byggserver’n stopp Alt jeg tenker på er test og kode og bygg og mat hver bidige dag Alt kan refaktoreres, alt kan leveres Alt kan refaktoreres, og ingen ting blir bedre

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.

På dagens møte i IASA Oslo fremsatte jeg påstanden at vi trenger en “vær-varsom plakat” for arkitekten. Spesielt fokuserte jeg på virksomhetsarkitektens rolle og risiko. I diskusjonen etterpå kom vi inn på mange av aspektene og det var mange veldig gode forslag der jeg ikke fikk notert meg alt, så jeg har utelatt mange ting som kunne vært sagt. Her er mitt førsteutkast til “vær-varsom plakaten”: Hold tilbake til innflytelse: Når du foreslår en løsning, kan løsningen bli valgt ukritisk.

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.

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:

[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.

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.

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.

This is a rough Norwegian language translation of the article JKE Day 1: Toyota Kyushu - The Manufacturing Ballet by Kevin Meyer (improvements on the language are very welcome, comments on the contents should go to Kevin). The reproduction has been authorized by the author. Unlike the rest of my site, this article is not available under creative commons license. Jeg kom over en artikkel som demonstrerte hvor bemerkelsesverdig lean production system kan være.

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.

I’m going on the road again. This time it’s not far, just to Trondheim for a seminar for the Norwegian computer association that I will be giving together with Aslak Hellesøy on agile development and testing. This will be similar to our line-up at JavaZone: Aslak will cover “how to make the correct software”, and I will cover “how to make the software correct”. Hopefully, we’ll make a few test managers think and a few others angry.

The Norwegian Agile User Group conference, Smidig 2008 was on Thursday and Friday. Both days started with three hour sessions of Lightning Talks, followed by three hours of open space work groups after lunch. We have been very happy with the format. The lightning talks give people food for thought. The best lightning talks are formulated around a provoking hypothesis. Kai Gilb talked about how we should focus on value instead of function.

The videos from JavaZone are up. Here’s my talk about Extending Continuous Integration, which talks about how I automatically run system level integration tests after every build.

I don’t normally post just a link to another blog, but More thinking about “Agile” vs “Waterfall” by Jason Yip is just too important. It the most well-argued, well-referenced, short post I’ve seen about the subject. Here’s a taste: Be careful about saying that Waterfall is more disciplined. The waterfall model is simple and structured but the “discipline” is in following prescribed steps as opposed to “discipline” in thinking. The second kind of discipline is by far the more important.

Warnings are useful. You get warnings from your IDE when you write something that might be a bug. You have probably made your program print out warnings or error messages when something goes wrong. But too often, we down in the sheer volume of warnings. Then it’s impossible to separate the relevant and important warnings from the noise. To make warnings useful again, I use a zero-warning tolerance policy. Even if the warning is irrelevant, I fix it.

This Norwegian language post describes my response to the report from a task force exploring a common IT-architecture for the public sector in Norway. Den norske regjeringen har besluttet at en felles IKT-arkitektur for offentlig sektor ville være fint. Jeg fikk greie på arbeidet på tirsdag, og har lest rapport til den store gullmedalje. Jeg er fortsatt ikke helt sikker på hva som menes med “felles IKT-arkitekt”, men jeg kan se omrisset av mange store evighetsprosjekter i dokumentet.

Sometimes it feels like I’m stating the obvious. But the fact that users only care about the interface of the service is something we often say, but seldom understand. If this is true, how can we think that we can develop the interface as an after though to the central system. Not all your users might be human. And the computerized users are treated even worse. If the non-human users also care about the interface, how do we think that they will be satisfied with the same interface that is used internally between different parts of the application?

Looking back at my projects for the last two years, we’ve had a tremendous improvement in the way we’re working. There are many things that we have done to make it better, and I’m be hard pressed to pick just three things I’ve learned. After much consideration, my favorites are: Partial production; Whole team; Requirements = Tests. Partial production: Using real production data for production in various scenarios has been extremely helpful.

At the last meeting in Oslo Lean Meetup Geoff Watts talked about BTs transition to agility. The most memorable part to me was when BT transformed a huge, waterfall type project with a delivery schedule measured in years into an agile project. The project set out to convert all BT customers to a new network with a brand new set of services. The new objective was simpler: Deliver one service to one customer in eight weeks.

People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode. The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling.

Three years ago, I was asked by one of our teams to give advice on how they should write a parser for a structured file format. Just having read up on SAX again, I recommended that they looked into designing it as a push parser. A push parser works by the design that the parser generates events each times it reads parts of the input. These events are sent to an event handler, which then builds up the internal object structure or whatever the program needs.

Warning: This article requires a lot of editing love before it is very useful. It might be somewhat incoherent. Read at your own risk. ;-) Silo (software): A silo system cannot easily integrate with any other system. In software, the term “silo” is used to refer to a system that is constructed as one unit from the front end to the data storage. Everything is tied together to work with the rest of the silo, but not with other elements.

This article is a Norwegian-language version of my article Four bold claims about SOA. Dette er et utkast til en artikkel jeg ønsker å få publisert. Jeg setter stor pris på tilbakemeldinger om uklare tanker og formuleringer. To av de vanskeligste problemene vi møter innen programvareutvikling er integrasjon og det som gjerne kalles “business-IT alignment” eller forretningsorientering, altså: IT skal understøtte virksomhetens strategiske mål. Tjenesteorientert arkitektur, eller Service Oriented Architecture (SOA), hevder å kunne løse begge disse problemene.

Three challenges for agile projects When I join projects now, I want to challenge all the stakeholders to make three commitments: Simulate production at least monthly: The software should be run in an environment that is comparable with the target production environment with loads and data variations similar to that of production. Thus, the technical stability of the project is proved. Demo with the business side at least monthly: The results of the project should be showed to the product owner, or perhaps even the end users.

As my previous Norwegian language article turned out to be one of the all time top hit articles in my blog, I will continue to write a few articles in Norwegian. This one is on an idea on how to do reseach on the success of agile projects. Next week, I will return to another popular topic: Testing. Under paneldebatten på Geilo-seminaret til Dataforeningen, satt Magne Jørgensen meg, Lars Arne Skår og Niklas Bjørnerstedt litt til veggs med et ganske enkelt spørsmål: Hvordan kan vi vite om smidige metoder virker?

What is the secret to happiness? Surprisingly, this question can be answered more and more definitively. I want my work to be conductive to the happiness of myself and others, and I believe agile methods can help me do that. Years of research into happiness can be summed up in a simple sentence. You all know what gives you a happy life. It’s not anything strange or unexpected. It’s simply enjoyable progress towards a meaningful goal.

Two of the hardest problems of software development are integration and what we could call business-IT alignment: The whole organization working towards the same goal. SOA claims to address both of these problems. After listening harder than I’ve ever done before to SOA evangelists, I think I understand what mechanisms SOA proposes to solve these problems. I think the idea of SOA is based on a set of rather bold claims:

When I give talks on agile, people often ask the inevitable question: “When is Agile not appropriate?” My response is that I don’t really care what people call what they do. What I am concerned about is the quality and frequency of the feedback that informs the control and decisions regarding project management and technical decisions on my project. I find the idea that you might not want to improve your feedback to be very odd.

This post is a Norwegian language summary of a talk I did April 14th, 2008 Jobber du smidig? Jeg jobber ikke smidig. Men jeg jobber smidigere enn jeg gjorde for tre måneder siden og enda mer smidig enn jeg jobbet for et år siden. Og om et år kommer jeg til å jobbe enda smidigere. Men Smidige metoder handler ikke om et mål, de handler om konstant forbedring gjennom bedre og hyppigere feedback.

A number of great sins have been committed under the guise of making software more maintainable. And 60% of software cost is during maintainance, according to Robert Glass. So what goal could be more laudable to pursue? The only problem is that we call things maintainable which are not. Putting remote interfaces in your application is done to “make it more maintainable”, creating frameworks is done to “make it more maintainable”, using EJBs is done to “make it more maintainable”.

Tal Ben-Shahar writes the following in “Happier”, his introductory book into the field of positive psychology: “The proper role of goals is to liberate us, so we can focus on the here and now.” In order to help us have a fulfilling life, our activities should both be meaningful and pleasurable. In this sense, meaning means to have a long term goal, pleasurable means to have a short term goal.

It’s been a year since my project replaced IBM WebSphere Application Server with a Java SE solution embedding Jetty. Looking back on the last year, I only have one regret: That it took us so long to make the switch. The difference takes a bit of perception: Our software no longer eats away our time, killing us with a thousand pinpricks. But WebSphere is just the most blatant example of software that gives you nothing, gets in the way of a lean process stream, yet costs a lot of dough.

Whenever I talk about Agile Software Development with people who have a strategic point of view, a very pertinent question always comes up: What about fixed price projects? Establishing an initial relationship with a customer about creating a product is often perceived as a weakness of Agile methods. After being asked the question very many times, I’ve started giving a fairly standard response, which is basically the same as Tom Gilb gave me when I asked him: Make the bid together with the first iteration of finished software.

Mary Poppendieck has just published a presentation on Agile software development entering the mainstream (and how to fail with agile). The presentation contains a number of insightful key points, but one footnote struck a chord with me: According to Allen Ward’s “Lean Product and Process Development”, Handsoffs are the biggest waste of product development. This has long been a pet peeve of mine, and I want to examine why handoffs occur, why they are expensive and how to avoid them.

What is a good measurement of the quality of your architecture? The length of your documentation. The shorter, the better. There are three purposes of documentation that can be important to a project for its long time survival. First: How does a new developer get started working on the project. Second: How do you install the projects executable on a brand new server. Third: What do you have to know to monitor and operate the system.

I went to Simula Research Lab’s seminar on estimation today. My conclusion is that despite many years of practice and research, we don’t know how to make estimates for even moderate projects correct within an order of magnitude. I think a new approach is needed! I wish I could’ve said that I learned something fundamental, but instead, I got my preconceptions confirmed. I think I understood the underlying causes better, however.

The Norwegian word “smidig” means “agile”. So when we wanted to make a Norwegian conference for the Oslo Agile community, “smidig 2007” (November 26th and 27th) was a natural choice for a title. The seed of the conference was idea by Nils Christian Haugen and Aslak Hellesøy to have a whole day devoted to open spaces. Meanwhile, I had been experimenting with “lightning talks” on Oslo XP meetup, a user group that meets in Oslo every month.

My talk at JavaZone went surprisingly well. The fact that the projector went dead and that I was planning on opening with a demo raised my pulse, but I felt I managed to get my message across and that people were happy. The talk was about how we use Jetty to manage the full deployment life cycle of our application. I explained how we had implemented this and what problems we had solved.

Sometimes, a quick and easy programming language like Ruby might not be so quick and easy. Sometimes, C may be easier. Sometimes, you might complete a task faster with C than with your favorite scripting language. I’ve long been a proponent of scripting languages. In particular, I’ve enjoyed learning and using Ruby. So when I was inspired to program a boggle solver as a code kata, I naturally reached for this nice shining tool in my toolchest.

Why can Scrum deliver surprising results already in the first month of adoption? Because it helps the team focus on what’s really important. We had Jeff Sutherland visit Oslo XP meetup a few weeks back. Jeff is co-creator of the Scrum method (with Ken Schwaber) and CTO of PatientKeeper, a US health information company. His presentation focused on the effects of Scrum on distributed teams, and on the effects of adopting Scrum in projects.

I have been going to the Recent Object-Oriented Trends (ROOTS) conference in Bergen for the last seven years, the last two years as a member of the program committee. It always strikes me how this conference gives me a different view on what I thought I knew, instead of just teaching a few new programming tricks. The conference is a well-kept secret. The intimate and conversational atmosphere gives everyone attending a chance to discuss software developments with some of the great minds of our field.

Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “requirement tests”. However, what unites the tests are more important than what divides them. The divisions are fuzzy, and they should be. All tests have but two purposes: To tell you if you’ve completed a new requirement, and to ensure that you haven’t broken something that worked.

The idea of effective reuse is a pervasive one. Software organizations have searched for ways to avoid “reinventing the wheel” for as long as there has been a software industry. But all research on research on reuse indicates that it is much more expensive than people expect. There are a few delicate balances that a reuse effort needs to observe. The ones I’ve notices the most have been Quality versus Expediency and Control versus Evolution.

Inspired by the “Hi, I’m a Mac” ads of Apple, Gregg Pollack and Jason Seifer has made these cute Ruby-on-Rails ads (featuring Ruby-on-Rails versus Java and Ruby-on-Rails versus PHP): Click here to view on YouTube

After spending more time than I care to indulge trying to get commercial application servers to behave, I finally decided to Do the Simplest Thing that Could Possibly Work, and create a new application server from scratch. Well, not really a full application server. For 90 % of the Java applications out there, all that you really need is Servlets, so I limit myself to that. And not really from scratch.

There’s one question you really should be able to answer about your software project, whether you’re a project manager, a tester, an architect or a developer: “How are we going to put this safely into production and get it out again if we need to?” I think this is what Configuration Management tries to answer, but it gets bogged down in so many details that I’ve never been able to say that I’m able to understand what configuration management is.

CIO JP Rangaswami at investment bank Dresder Kleinwort Wasserstein talks about why he considers open source a corporate IT asset. In this talk, Rangaswami describes how DrKW wanted to create an internal incubator environment in order to combat skill attrition in the late 90s. In the course of doing this, they acquired OpenAdaptor and discovered almost accidentally benefits of the open source development model. The talk is a bit fleeting and unstructured (and someone’s phone keeps ringing during the presentation!

This post is currently only a draft. Input on how to improve the structure is very welcome “A journey of a thousand miles begins with a single step.” - Lao-Tzu When doing architecture, we always have to content with the present state of the system. It is extremely tempting to ignore this picture of the ugly system and create your vision of how things should be in the future. It is also very easy to get people to agree on such a vision.

Sverre Huseby examines some security issues with Spring-MVC. As it turns out, the Spring JSP form-taglib provide no HTML-escaping by default, making it very easy to get Cross-Site Scripting vulnerabilities included in the code. The article comes complete with a standalone application that illustrates the problem. Comments: [Anders Furseth] - Mar 7, 2007 As interesting as this is, Sverre has yet to report the issues to the Spring-MVC team, making this premature disclosure unethical at best.

Update: Added retrospective result example I learned by favorite team building exercise on the ROOTS conference in Bergen three years ago. Alistair Cockburn conducted a great workshop that really drove home the lessons of iterative development at the same time as it showed a very useful technique for conducting retrospectives. I have later conducted the same exercise as a workshop in different situations. Maybe the most fun occasion was Oslo XP Meetup March 2006

Some time back, I watched a video David Heinemeier Hansson give a talk on ActiveResource on RailsConf. The thing that struck me is how much Rails’ ideas are connected to those of Domain-Driven Design. Watching DHH is like seeing a version of Eric Evans on speed. The video is long, but very entertaining. And it is well worth watching even if you couldn’t care less about Rails. DHH explains in real concrete terms how to think in terms of Domain-Driven Design, even though from the sound of it, I don’t think he’s heard of the term.

Based on the US Department of Defense standard DOD-STD-2167A, we have a well-defined process often referred to as Waterfall. If you are not familiar with the process, here is a short introduction. A project in the waterfall process goes through four phases before the project is completed. The first phase is the naïvite phase. This phase should always last 12, 18 or 24 months. 18 months is recommended. There is a detailed plan showing how, at the end of the phase, the system will be done.

In a recent thread on the Pragmatic Programmer mailing list, Dave Stagner said: [….] I think most software hovers near the border between “barely works” and “almost works”. Comments: [dave] - Aug 1, 2007 So much for my 15 minutes of fame. :}

Lately, I have had the rather dubious pleasure of reviewing some of our existing systems and find a plan for improving the maintainability of these systems. I have not done much work like this before, and I came in unprepared for the experience. Most systems that have been maintained for a number of years have a maddening complexity, especially if they include a range of technological elements. Cramming the systems into my head completely enough to not make recommendations that are counter productive when they are faced with reality requires me to digest a lot of detailed information from many sources.

Updated (again) based on comments from helpful readers Recently, I have discovered that managers who come into Java projects are totally unprepared for the reality that they face. Some programming environments have been basically stable for decades. COBOL has been stable from before most of us were born! But Java is different. There are a few things you need to understand about Java. First of all, Java is not a programming language.

How do you control an agile project? I have had many discussions with people lately about how to manage the budget and estimation of an agile project. The following post argues that a project with a business case of $20 million should deliver in steps of no more than $500,000. The argument is sadly only based on “common sense”, and not on actual project experience. (There are too few Agile managers in Oslo)

Do you speak test? In that case: Hello web application: public class WebIntegrationTest extends net.sourceforge.jwebunit.WebTestCase { public void testIndex() { beginAt("/index.html"); assertTextPresent("Hello world"); } private org.mortbay.jetty.Server server; protected void setUp() throws Exception { server = new org.mortbay.jetty.Server(0); server.addHandler( new org.mortbay.jetty.webapp.WebAppContext("src/main/webapp", "/my-context")); server.start(); int actualPort = server.getConnectors()[0].getLocalPort(); getTestContext().setBaseUrl("http://localhost:" + actualPort + "/my-context"); } } This code runs with no application server, no separate deployment step, just like that. If this looks interesting, see my full-sized article on java.

The more I code, the fewer dependencies I am willing to create. For example, I used to have a common super interface that all persistent objects must inherit from in order to have an id-field. I used to have a common DAO interface that all DAOs implemented. But these add hard dependencies in my code. Hiding the super interface for all entities was easy. Doing away with the DAO is harder.

Ralph Johnson discusses the use of Relational Database Management Systems (RDBMS) If you don’t have good architects, big systems will end up as big balls of mud. A lot of companies live with it, but there are certainly big payoffs if you can avoid it. The main problem is that there aren’t enough good architects to go around. One of the advantage of a RDBMS is that it is fairly easy to understand so below average programmers can still get systems running.

This post is an entry in my ongoing series about web integration testing with Jetty. See post 1, 2 and 3 in the series for more information. I often find that a web interface needs to let a user select one of a list of objects as a relation to the object he is editing. This is the basic and simple way of dealing with many-to-one relationships. However, most web frameworks don’t make this as easy or well-documented as it should be.

In my previous two posts about integration testing with jetty [1][2], I have showed how to test a simple web application with Jetty and how to expand this application with a fake DAO implementation to test display and updates of data through the web interface. In this penultimate post, I will describe how to work with more advanced edit scenarios. Most web applications have some degree of requirements for validation of input and a bit more advanced data structure than the one we’ve worked with so far.

Do you speak test? In that case: Hello web application: public class WebIntegrationTest extends net.sourceforge.jwebunit.WebTestCase { public void testIndex() { beginAt("/index.html"); assertTextPresent("Hello world"); } private org.mortbay.jetty.Server server; protected void setUp() throws Exception { server = new org.mortbay.jetty.Server(0); server.addHandler( new org.mortbay.jetty.webapp.WebAppContext("src/main/webapp", "/my-context")); server.start(); int actualPort = server.getConnectors()[0].getLocalPort(); getTestContext().setBaseUrl("http://localhost:" + actualPort + "/my-context"); } } This code runs with no application server, no separate deployment step, just like that. If this looks interesting, see my full-sized article on java.

The security people at my were suggesting that we needed to create an encryption service, to securely store passwords so that even rogue DBAs could not get at them. The idea is that no matter how good your access is to the database, you shouldn’t be able to decrypt the passwords unless you have the secret key. In a solution like this, the key is generally stored offline with the application and loaded into memory sometime during startup.

In my last post, I wrote about four integration scenarios using databases: Reference data, Consolidated view, Subscription and Publishing. Of these, the Consolidated View scenario requires the most interaction between the server and the client roles. This post will examine how to make the pieces fit together. Consolidated view joins the data of multiple clients into a consolidated view. This makes you able to create administrative applications that span a set of subapplications without having to change the central view when a new application joins the mix.

In my last post on using the database for integration, I argued that the best metaphor for creating systems that are interconnected is that of One-Large Database. Carl-Henrik asked some very relevant questions about this, which I will interpret (for now) mainly as “how do you avoid drowning in complexity”. This post will address the issue of maintainability, especially when things grow to be large. The On Large Database metaphor is mostly useful as a starting point.

Due to popular demand, I will post a very short version of my Lazy Loading article: Why? Because this is bad: Category category = dao.get(1); Category parent = dao.get(category.parentId); int sumChildValue = 0; for (Long childId : parent.subcategoryIds) { sumChildValue += dao.get(childId).getValue(); } System.out.println(sumChildValue); This is good: Category category = dao.get(1); int sumChildValue = 0; for (Category sibling : category.getParent().getChildren()) { sumChildValue += sibling.getValue(); } System.out.println(sumChildValue); And this is better:

Status: This article is currently pretty dry. I’d like feedback on how to make it more eloquent. In my previous blog post, I promised to write more about using databases as the main integration strategy. In the current post, I plan to cover maybe the most important question: “Why?” Imagine an application where every time it wants to communicate with another system, it reads or writes to the database. For now, let’s ignore how this would work, and how it would evolve, which will be the subject of later posts.

Before Web Services, there was CORBA. Before CORBA, there was DCOM. Before DCOM, there was RPC. Before RPC, there was BSD sockets. Before sockets, there were databases. And as it was in the beginning, so shall it too be in the end. The only systematically successful strategy in the history of computing is databases. I have discovered more and more lately that integration using a database is well-defined (DDLs - a WSDL that works!

Update: Rewrote several sections “Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it.” - Alan Perlis This article contains some things I have learned that has made me into a better developer than I was before I learned them. There are nine tips. These are not necessarily the only, or the best things I have learned, but I like the number nine. Becoming a better developer is a complex path.

Updated for republication in Mr Bool In my experience, the most serious bugs in programs in production are in error handling routines. Inventive programmers often try fancy things when dealing with errors, but error situations are often omitted during testing. This article examines the fundamental questions of exceptions: What causes exceptions, and what can be done with them? Bad User, Bad Server, or Bad Programmer Practices of an Agile Developer puts exceptional events into three categories:

When I see people after they have read about SOA or attended a conference with SOA, there are a few ideas that seem to pop up repeatedly. I have even been guilty of using these ideas myself. These ideas were proven to be bad before SOA came around, and (some) SOA evangelists seem to think that SOA solved these problems. It did not. It just refused to learn from history. Some of these ideas work under some circumstances, but recent SOA-itis has caused them to be used in inappropriate contexts.

Barcelona I just returned from The ServerSide JavaSymposium Europe. Great conference, with interesting tracks and good opportunities to get to know people. The conference was in Barcelona, which was interesting, because hardly anyone (taxi drivers and waiters included) understand English here. It’s the first time where I’ve been a place where I am totally unable to communicate verbally with people around me. So it as a bit of an adventure. My only gripe about the location is the price of WiFi access in Spanish hotels.

Roger Sessions has just published “A Better Path to Enterprise Architectures”. His main point is that large, centralized, big-bang enterprise architecture efforts fail. I could not agree more. Sessions gives some good arguments for why you would want to deliver incrementally. He calls this approach SOA. This is a fairly common way of defining SOA - basically SOA is another name for incremental deliveries. If this is SOA, I don’t hate SOA at all.

In my previous post, I talked about how I feel SOA encourages rigid design. Of course, in some situations, you may not really have a choice. When creating Business-to-Business (B2B) integration, interfaces will naturally be much more rigid. There is no way around it, SOA or SOA-not. Ian Robinson recently published an article on Martin Fowler’s webpage titled Consumer-Driven Contracts: A Service Evolution Pattern. The article gives some very clever ideas of how to make the consumers drive the service definition instead of doing this on the provider side (this is related to Lean Software Development, by the way).

This post is an analysis of the difference in philosophy between static and dynamic typed languages and the pragmatic ramifications of these philosophical differences. I will use Nil/Null/None-types as basis for the example. The Nil-value is used in OO programming languages to designated a non-assigned value. Any object reference can be nil, which gives it a special role. In effect, Nil is an instance of all types. This is a concept that can only be expressed in a language that supports multiple inheritance.

Aslak Hellesøy created the …. interesting tool Guatanamo. From the documentation: “Do you have problems maintaining high test coverage? All code is guilty until tested innocent. Send the untested code to Guantanamo!” (that is, delete it) I think this is a very interesting policy, and even though it is too extreme to ever be practical, it reveals an underlying principle: If code doesn’t have tests, it doesn’t have value. Chances are that it is rigid, poorly designed, and wrong.

I am planning to see if I can do some more work on test automation. I have discovered that I am pretty good at going into existing code bases and adding tests now. In order to practice, and to have something to demonstrate, I would like to find a deserving open source project that I could add some unit tests to. The design of the project doesn’t have to be good.

Writing my previous post got be thinking about code comments. I have seen a lot of bad comments in my years, and I’d like it to stop! Here are a few examples from the horror cabinet of the world of code comments. Stating the bloody obvious Never, ever, say in comments what the code already says. Ever: class Bar { /** gets the foo of the bar */ public String getFoo() {.

David Heinemeier Hansen’¨s talk at OSCon is available at IT Conversations. For those who don’t know, DHH is the man behind the big rising star of 2005: Ruby on Rails. Favorite quote: “Too many technologies are chasing flexibility as thus it was free. It is not. Your exchanging flexibility for velocity in development, for a delay in changing you mind, and it is really a bad notion! … In other terms, constaints are liberating”

I have been working as a Software Architect for several years now, but I still find myself unable to answer the question “what is software architecture?” However, I think I can point to some of the factors that can make the architectural work successful. First: Architecture is about vision, communication and governance. The vision bit is relatively simple: Any company has huge inefficiencies in how it operates. I think the very nature of business is such that these inefficiencies have to exist.

C# 3.0 is Right Around the Corner (in the Microsoft sense of the word…), and it brings to bear a lot of interesting features. Most of them come together in the technology called LINQ (Language INtegrated Queries). Even though I doubt I will use C#, I think there is a lot that can be learned from this preview release. Let’s take a look at an example Query: var contacts = from cust in customers where cust.

For the most part I think Ruby on Rails is pretty much the best thing since sliced bread. Of course, like everything else, there are some issues I’m uncomfortable with. Mostly, it has to do with deployment, and especially security during deployment. SwitchTower deploy.rb configuration file contains source repository password. This is a consequence of the fact that the application servers check out code from the repository. When using SwitchTower the source repository must be available from the application servers.

Everyone is talking about SwitchTower these days, so I just had to check it out. When I got it to work, I was quite pleased with how it works, but there were quite a few issues along the road. First of: What is SwitchTower? Basically, it is a tool for automating deployment of applications, focused around Ruby on Rails. With SwitchTower in place, I am able to write stuff like “rake deploy” and “rake rollback”.

Joel Spolsky had a blog entry seems eerily familiar: The Architecture Astronauts (in outer space) I’m starting to see a new round of pure architecture astronautics: meaningless stringing-together of new economy buzzwords in an attempt to sound erudite. I’ve seen the type, and I’m glad to say that we haven’t got any of those around. A bad architect can cause enormous damage.

I just got published last week: My article Unit Testing Hibernate Mapping Configurations was last week’s featured article in java.net. This is the first time I’ve really been published (at least been paid for it!). I found the experience interesting and (mostly) fun. Many thanks to the editor, Chris!

Updated for republication in MrBool. As readers of my blog must have noticed by now, I am somewhat of an advocate of Extreme Programming (XP). However, for the last nine months or so, my title has been “Lead Software Architect”, and I am the (proud?) author of what Martin Fowler calls “the almighty thud” documents. XP is traditionally skeptical of architects, and often with just cause. I’ve frequently heard the term “architect” defined as someone who restricts the options of developers – a definition I don’t particularly care for.

The most recent issue of the Norwegian ComputerWorld contains several articles of interest from an open-source point of view. In addition, the subject has come up for discussion at work recently. Who benefits from open-source? Primarily, it is the consumers of software. Yet the consumers of open-source devote very little resources to developing open-source software themselves. Perhaps they should? The hardest issue for organizations using open-source contribute time and money to the development of open-source is the fact that it is hard to see that this is money well spent.

I like metadata for some tasks. Luckily for all of us, Commons-Attributes implements metadata for pre-Tiger JDKs. Unluckily, it requires an extra compilation step (with Ant, no less). But no more. I’ve created an extension that does it all in memory. The class uses both xjavadoc and commons-attributes. Here is an example of usage: CommonsMemoryAttributes attributes = new CommonsMemoryAttributes("src"); Class testClass = AttributeTestClass.class; public void testClassAttribute() throws SecurityException { Collection result = attributes.

How should development teams be organized? Reduce chatty interfaces. In Lean Software Development Mary Poppendieck describes the seven wastes of production and their analogy in software development. Three of these are: Motion (software analogy: Finding information), Waiting (Waiting), and Transportation (Handoffs). I see these in many projects that I am involved in, or hear about. One problem many organizations experience is a divergence of software developed by different teams. This is a serious problem, but many organisations choose the other extreme.

When I have been using easyMock Mock Objects for testing I often find it helpful to intersperse expectations and test code, for example: mock.start(); control.replay(); server.handleCommand("START"); control.validate(); control.reset(); mock.shutdown(); control.replay(); server.handleCommand("STOP"); control.validate(); Doing this with easyMock requires me to validate and reset the object frequently. I was thinking: What is stopping me from just calling doing this: mock.start(); server.handleCommand("START"); // call from the object-under-test, mock automatically assumes replay mode. mock.shutdown(); // Call from the test-harness puts mock back in record mode.

Spring has shown us how to effectively separate the business logic from data access logic. This allows for easy testing of business logic without having to deal with the database, but it does not provide any easy way to test the DAO code. A new feature in the Hypersonic database might just be what the doctor ordered. HsqlDb 1.7.2 introduced RES urls. If you access your database with a RES-url, you get an in-memory database initialized with data in a jar file in the class path.

On JavaZone (which was an huge success, IMHO), Richard Stallman was the guest of honor. He talked about the four freedoms which free software gives you, how the Sun Java implementation is not free, and why that might concern us. Then, he talked about something that should concern all of us, even if you think Free Software is bogus: software patents. As I understand Stallman, if software patents become law, you can violate a patent without knowing it.

When I look back at the lessons from User Stories Applied, I realise that many approaches to requirements muddles different purposes of requirements together. There are three things requirements need to address in one form or another: First, the development team needs an understanding the needs (requirements) of the user. Second, the project needs a specification of what is inside and outside the scope of the project, as well as the priority and status of different deliveries.

Today I attended a meeting where IBM/Rational got to extol their glorious Unified Process (RUP). RUP has a lot of good sides, and I think a lot of the high-level ideas are very good. Phases, workflows, artifacts, and roles all make sense. The concepts can be used to understand any process, even “non-processes” like code-and-hack. The central question then is whether the components of RUP individually are the right ones for a given project and whether their composition is appropriate.

I have a confession. I looove gadgets. With many knobs and blinking lights and cool stuff. Stuff like Blinkenlights makes me quite excited. When I was young, I used to play with hours with math. I invented the hyperparabola, which was my own term for a formula that combined a hyperbolic function and a parabolic function. I could make a neat curve based on the formula. Opening Rational’s RUP tool gives me the same feeling.

Extreme Programming vs. Interaction Design Elden Nelson interviews Kent Beck, the founder of the Extreme Programming method and author of “Extreme Programming Explained: Embrace Change”; and Alan Cooper, the prime proponent of interaction design and author of “The Inmates are Running the Asylum”. The interview is well worth the effort of navigation through the horrible interaction design of FTPOnline. Beck’s analysis of interaction design and “Inmates” expresses exactly how I felt about the book when I read it: Interaction design has a lot of really powerful tools to really important questions.

Yes! The first thing that strikes me about Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software” is how it seems to bring together the ideas that have resounded the best with me during the last few years. The central thesis of the book is that that enterprise software should to be built around the model that (non-software) experts in the field has of the problem domain. The shared understanding between the software developers and the domain experts and users facilitates communication.

I was recommended “The Art of UNIX Programming” by Eric Raymond (esr) from Joel Spolsky’s “Joel-On-Software” blog. The recommendation in it self warrants some comments, as Joel Spolsky normally is very much a Windows-kind of guy. Despite the title, the book definately has much to offer people who never touch UNIX as well. esr focuses on the cultural aspects as much as the technical aspects. For organisations that are migrating into Unix infrastructure the ramifications of the Unix culture can be hard to grasp.

Oh No! DTO! Should DTOs have public variables? Or should they have private variables with getters and setters? [via Artima Weblogs] Finally someone with a little sense on the subject. Notice that this fits in with the idea of “accessors considered harmful”. (Which, just for the record, I noted before Holub) A final observation by Dave Astels: “Sometimes a data structure is just a data structure.”

I have been looking for a while for a refactoring tool that could improve the encapsulation of my code. More specifically, I want to be able to analyse a closure of code (like what JDepend does), and make methods private, package protected or protected as much as possible. Of course, if it is to be useful, there has to be a good way of defining root classes and methods, ignored name patterns (getters/setters for those who are still addicted to those) etc.

Martin Fowler has an excellent piece about MDA on his blog. Also be sure to check out Fowler’s link to Dave “Bederra” Thomas’ article on UML. It seems like quite a few people who are knowledgeable about MDA dislike Fowler’s article quite a bit. I thought it was time someone who knows MDA and is not starry-eyed about it chipped in. Yeah, that would be me, your humble host ;-). I have worked quite a bit with Compuware’s tool OptimalJ, and presented this tool in many forums.

I have been real bad about writing in my blog lately, but I am finally back. It’s been a crazy few months, including a new job, which of course takes up some time. I have now officially stopped working as a consultant, but I still take some projects on the side when time permits. My next interesting event will be Software 2004, where I am both a speaker at the .

Note: This term is also used about mixed economies. Central dogmas: The purpose of government is to work for a vision of a good society A good society is one where wealth is distributed in such a way that no-one suffers and everyone is given incentives to produce at their fullest capability. Distributed control is superior to central control Monopolies hurt

If a beginning programmer was to read just one book, this would definately rank high on a list of candidates. (But then again, why should a beginning programmer only read one book) “Agile Software Development: Practices, Principles, and Patterns” is in many ways Robert C. Martin’s magnum opus. After having read much of his papers on Dependency Inversion Principe, the Open-Closed Principle and other object-oriented methods, as well as Extreme Programming, Agile Software Development puts it all together.

I have come to a conclusion: I do not want to be on any more fixed price, fixed scope projects. From what I hear, that is all the projects the consulting business is getting today – if that is the case, I will have to find something else to do. The main reason I take this stance is simple: To me, seeing the value of my work in the real world is the only real measure of accomplishment.

Update: Cleaned up mess made by “WYSIWYG” tool) Rating: Must-buy The agile movement has started to gain speed and become more mainstream, and the Poppendiecks’s “Lean Software Development” added an important part of the puzzle for me. Like so many manifestos before it, Lean Software Development compares software development to other industries (lean thinking takes its roots in the Toyota manifacturing system). However, the authors reach a very different set of conclusions.

The video from my presentation at this year’s JavaZone are available. The conference has done a lot better job of follow-up this year than last. Thanks, JavaBin. This is actually the first time I get to see a full-length video recording of myself speaking. I was afraid I would be real disappointed, but I am actually fairly happy. Most of the problems with the presentation was things I already was aware of, like the fact that I had way too little time.

(Warning: Boring, personal entry) I am writing this entry on a bus. More specifically, on the bus from the airport to the conference Sanntid 2003 (Real-time 2003), where I am scheduled to speak tomorrow. The airport in question is Kjevik airport, which is a military/civilian airport in the south of Norway. Normally, when I ride busses, I like to read. I brought along Mary Poppendieck’s fascinating “Lean Software Development”. This time is different.

[…] Are those CMM-mandated procedures too difficult and onerous to complete? People will find a work-around, bypassing the intent of the CMM and filling in whatever documents are required to get by. Is that comprehensive (and manual) test plan overly lengthy and tedious? People will take short-cuts. The “extra-legal,” or alternative system will evolve in any social setting where the official mechanism doesn’t cut it. […] [via /\ndy’s Weblog] Andy excellently connects the dots between file-sharing, development of societies, and software engineering methods.

Beyond Software Architecture (Luke Hohmann) is an invaluable read for any aspiring project manager or program manager. There is so much more to getting successful programs out the door than just the classical analysis, design, development, test. The most important feature of this book is how it helps frame software development in a larger picture. The point of software development is to create value for someone. It is important not to lose sight of that fact.

I came to remember my thoughts on Open-Source software while talking to a friend after lunch today. The idea is that even though reuse of third-party software is something that a lot of companies want to encourage, we don’t really know the total cost of third party software. The problem as I see it is that under almost any circumstance, an organization delivering a composite product is always responsible for the totality of the product.

Just a little reminder list to myself. Check out this Java technology before next Java project: Pico Container eXo portlets Hibernate

Read: http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf. The following is an except: Ralph Johnson: So, a better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ […] the architecture only includes the components and interfaces that are understood by all the developers.” _ “[..] Johnson’s secondary definition [is]: “Architecture is the decisions that you wish you could get right early in a project.

I have just recovered from JavaZone 2003. This year was quite good. A lot of good speakers this year. I had great fun holding my presentation. I didn’t get through my whole program, but I do think people were entertained, and that was all I hoped for. It is a real rush to present for such a crowd. eXtremeProgramming.no god off to a good start. Along with the other funders, I got to meet Kent Beck.

Joel Spolsky, of Joel-on-software fame was in Oslo, and had an open invitation to dinner for readers of his website. I think around 30 people showed up, which totally blew my mind. It is always nice to meet people who care about software development beyond having a job to go to from 9 to 5. Maybe there is enough interest to have a regular network event for technical people who care about what they do?

Learning OO is such a disappointment. When you go from the models and into the code, you pretty much discover that it is all bunk, anyway. In your neat customer-order-product design, each entity explodes into circa 10 artifacts if you implement it in J2EE, or gets fragmented into mostly pure data management if you use .NET. You can hardly find the classes again anywhere in the implementation. What went wrong?!

On the Agile Management mailing list, David J. Andersen writes: It would get a little more involved than that but the you get the basic idea. Pay for the value delivered, not the effort expended. Incentivize the vendor to deliver high quality. Most agile methods use a variation of a backlog. In an ideal project, the payment would be only dependent upon the value of each feature requested. Most software projects are much more resilient to underdelivery than people realise (and less resilitent to late delivery), which makes this into an contract that keeps both parties interests in mind.

Ullman’s book describes the lives of two people related to a large software development project in the early 80s. Ethan Levin is the programmer who is judged responsible for the bug. As it proves to be impossible to reproduce reliably his life seems to spiral down into dispair, loneliness, and depression. Ullman is a master at describing the almost hypnotizing urge to “just fix this last problem before” when programming. The dysfunctional team and people in the novel are more dysfunctional than anyone I have ever met, but they are perfect carricatures (I hope!

I went to the rOOts 2003 conference this year. As always, it was a great convention. ROOTS draws a fairly small, yet advanced audience. A recurring theme this year seems to be agile development. It also seems like all the speakers concluded with the fact that “everything was better in the good old days” (more or less). This seems to be a sign of the times, and was also reflected in Alan Kay’s keynote at the O’Reilly Emercing Technology conference.

How Mortal These Fools Be… …Wherein we explore what it means to be a computer, or computation, or computrons, or a computer programmer, and why Ken is even touching a computer when he’s on vacation. (From Ken Arnold’s Weblog) [via Artima Weblogs]

Very noteworthy quote: “I think that in the long term the larger code generation efforts, the “application generators,” will become a thing of the past. They are there because the underlying technologies and architectures don’t yet support programming at a high level. " (Pragmatic Dave Thomas) Truer words were seldom said.

Test-Driven Development describes in detail this technique from Extreme Programming. In addition, the author spends some time teaching the reader a useful set of mental tools for writing better code. TDD is a very fast read, but it is full of useful information. If I wanted my developers to only read one small book about software development, this would be it. Note: The back of the book lists it as “Software Engineering/Testing”.