Trifork Blog

Posts by Alef Arendsen

Amsterdam Java Meetup – October 30th, Rain, Amsterdam

September 25th, 2009 by

Last Java Meetup was a great success with two short presentations. This time, we’ll have two presentations again. We have one confirmed presentation and are still working on another one.

The one confirmed presentation is from Peter Veentjer and will be about Software Transactional Memory and a project Peter is hosting at Google Code called Multiverse.

Soon, we’ll also confirm the other one.

No registration is required and this time, the venue will be a little more quiet than the last, so we can all safely enjoy the presentations :-).

So, mark your calendar with the following details!

Date: October 30th, 2009
Time: Venue open at 17.00, sessions starting at 17.30
Location: Rain – Rembrandtplein, Amsterdam

View Larger Map

Successful Java Meetup last Friday – feedback wanted!

June 7th, 2009 by

Last Friday we had another successful Java Meetup. This time we changed the format a bit to include two (very) short presentations. I didn’t want these presentations to take place in a boring office location or some kind of conference venue, so instead we settled for Werck, a nice bar and restaurant next to the Anne Frank House in central Amsterdam.

Read the rest of this entry »

Java Meetup June 5th – IMPORTANT CHANGES & RSVP

May 18th, 2009 by

Last few times we organized the Java Meetup there was just beer and talks. This time, it’s going to be a little bit different. When I ran into the Trifork folks at SpringOne a few weeks ago, Iben (one of the girls from Trifork) suggested we do a few presentations. She’d love to come to Amsterdam to see what the Java crowd is like here and to get some input on their various conferences around the world (JAOO, InfoQ, et cetera).

Read the rest of this entry »

Conferences, symposia en meetups

April 23rd, 2009 by

I left SpringSource about 6 weeks ago and haven’t really concerned myself with a lot of technical things since then. As part of my job at SpringSource I used to speak at conferences a lot. This week I had one of my first conventions ever where I purely had a commercial role and not so much a technical role. It was booth duty time 🙂 and I must say, it wasn’t too bad.

Read the rest of this entry »

Oracle buys Sun – consolidation and open source

April 20th, 2009 by

The news couldn’t be missed today. Both Sun and Oracle commented on their respective website shortly after the news hit the press and many people on blogs, twitter and other channels followed.

It’s interesting to see how much consolidation has happened in the Java community in recent years. First there was the major acquisition of JBoss by RedHat almost 3 years ago. Next was BEA, being gobbled up by Oracle little over a year ago. And, while the news that talks between IBM and Sun had stalled still hadn’t faded, the Java powerhouse is being acquired by Oracle. This means there are only a few public companies left with a large and prominent involvement in Java EE, most notably Oracle, IBM and RedHat. I shouldn’t forget Google for all their involvement in Java, but then again, their main business is still in ads, not selling hardware, software and services.

Read the rest of this entry »

Selling Agile Contracts Part II – The List of Contracts

April 20th, 2009 by

Okay, so we kind of concluded fixed-price contracts are evil but what are the alternatives?

Before we move on, let’s get the terminology right. Erik van Oosten rightfully commented we might have to start using the terms fixed-feature and fixed-term on top of fixed-price. To take it to a bit more general level, in a project there are three basic variables: a collection of features (or scope), the deadline (or schedule) and the budget (or resources). I’m specifically naming them scope, schedule and resources as these are the exact same terms Scott Ambler came up with in his article titled The Broken Iron Triangle Software Development Anti-Pattern. In his paper, Scott argues that ‘refusing the recognize the implications of the iron triangle’ is ‘one of management’s more popular approaches to hamstringing an IT project’. He goes on to say ‘we really need to question the ethics of “fixed-price” IT projects‘, which confirms what we’ve already settled upon.

The next thing he says (and this is completely obvious, if you’ve ever encountered an agile project done right) is you should be prepared to vary one (or even two) of the factors involved. Vary the scope, schedule or the resources that is, based on what you encounter during a project.

That’s nicely said and all, especially if you’ve won the client’s trust already, but what are you going to tell a customer that has a budget of say €100k for which you’ll quite likely implement something nice that suits his needs. The client puts out an RFP and invites three suppliers to answer to the RFP. You now it’s best for the client to end up in a situation where in cooperation with the client you can vary either scope, schedule or resources, but you have to win the client’s trust first.

I think the answer lies in the response to the RFP plus a certain amount of risk you’re willing to take as supplier to win this deal and this is where the list of contracts comes in that I got from Martijn Dashorst of Wicket fame. The list, by Alistair Cockburn provides various options for drafting a cooperation between the client and the supplier, varying from fixed-everything to fixed-nothing.

I’ll be digging through this list in the coming weeks to see if there’s anything usable. In the meantime, one thought I had was to be upfront with a potential client and offer him the various options for drafting an agreement (or at least, the ones we feel comfortable with). I’m not sure this will work in all scenarios. There are plenty of RFPs for example that require you to come with a response without being able to discuss possible directions with a client (how weird that may sound).

Apply for the Search Symposium @ JTeam – June 3rd

April 17th, 2009 by

More and more information is available every day, both out on the internet as well as internal to companies. Combined with the trend for organizations to increasingly enable self-service for their customers, it’s important to make all this information easily accessible. One of the easiest ways for customers to access information they need is by allowing them to search through the information.

The challenge is how to offer a nice and clean way for customers to search through these vast amounts of information. There are various enterprise search technologies out there. A few days ago, I talked to a friend of mine who had implemented the Google Search Appliance and other than that, you can obviously think about vendors such as Endeca or FAST. A (relatively) new kid on the block is Solr, an open source enterprise search solution.


At JTeam, we’ve always helped clients expose information in various ways. We’ve done this for clients such as Ilse Media (by implementing the frontend for the well-known Dutch search engine, and more recently i-local (online search engine for companies). We’ve used a wide variety of technologies to do all of this and we believe we have built up a good amount of knowledge in this area.

There are some interesting challenges to think about when settling on a strategy to make your information base searchable. Imagine things like multi-lingual information, customization of what to search for (documents, custom databases, SaaS platforms in use by clients such as Salesforce and the obvious package selection factors such as pricing, support, training and maintenance).

To get a better overview of what challenges you are facing while making your information available and searchable and to give you some insight into what we believe are the trends and technologies in this area, we’re organizing a Search Symposium coming June 3rd.

This event does not have open admission. We explicitly welcome decision makers of (semi)government or commercial organizations who are considering or currently involved with an enterprise search program–organizations that possess a substantial amount of information and are in need of an affordable & innovative solution that fulfills their needs. People that have a (strong) background in or affinity to search solutions and/or technologies are also encouraged to welcome to come and join.

This small and targeted event will take place on Wednesday 3rd of June, from 14:00 to 17:00 followed by some drinks at JTeam’s headquqarters in Amsterdam. There is limited space so make sure to apply soon at with a short description of your motivation for participating.

The BCG Matrix at JTeam – new & cool technologies

April 16th, 2009 by

Bram recently updated our website with a list of technologies that we at JTeam find interesting. The list (available from the JTeam website) currently holds things such as Solr, Spring, Flex and Wicket.

The things on the list do not come out of nowhere. We’ve always been a company partially driven by technology and innovation. We are always on the lookout for new technologies that can help us realize our projects in a more efficient yet exciting way. This way we became involved with for example the Spring Framework, which finally resulted in us co-founding SpringSource.


Recently, we decided we should visualize our view of the (technology) world a bit more and the format we’ve used is the BCG Matrix that puts a business’ activities into one of four categories. Paraphrasing and translating this to our business (the enterprise software deveopment industry), the four categories are

  • (Cash) cows – technologies with a high marker share in a slow-growing or mainstream sector that can help us big-time realizing our projects. Technology in this areas are regarded as being mature and sometimes possibly a bit boring. They generate money and interest though from a large amount of users in a sector that we find interesting
  • Stars – rapidly growing technologies with a high market share in the early-adopters area. We already use these technologies to realize projects in a more efficient way than we used to do. Technologies in this area are cool and regarded as being innovative. Potentially, technologies in this area can become cows if managed correctly
  • Question marks – technologies that grow quickly, but still do not generate significant amounts of revenue. Should be invested in in order to make them stars. Potentially technologies in this area could add to our ability to better service our clients
  • Dogs – technologies that (in our minds) do not add to our possibility to implement and maintain software enough, do not generate enough money to make a profit from given our current situation and/or are not interesting enough for us to invest time in

After having categorized the technologies that we use and might want to use, we ended up with a pretty solid matrix. The challenge with things like this usually is in my opinion how to make them part of the company’s mindset and to keep them alive. We long though about a way to make this happen and we settled on putting it up somewhere in a prominent area in the office. Not only did we want to put it up somewhere, it should be editable in a way.

To do this, I’ve ordered semi-permanent whiteboard markers. I didn’t know these things existed and found out about them after some Google’ing. They’re only erasable by using a wet cloth. This means if you scribble on the window or whiteboard using a normal whiteboard marker, you can still erase the scribbling, but not the semi-permanent stuff.

I’ve drawn up the matrix on the window near our lunch table. This way, we can look at it over lunch and discuss things. The window looks out over the city so people can also pretend to be looking at it, while in fact they’re enjoying the view.

It’s been up there for about an hour and people already began scribbling on the window to express their disagreement with the way some things are categorized. Also, some things have been added and some renamed. It seems like it’s working :-).

In the future, you can expect more blog entries about individual technologies on this list. Some opinions might be controversial or personal to one individual employee in the company, nevertheless they always add to the discussion about what should be in the matrix and where.

Amsterdam Java Meetup – June 5th

April 15th, 2009 by

Last March 13th, we had another pretty successful Amsterdam Java Meetup. One of the comments that I got was why I didn’t organize it more often.

So here goes: June 5th, there’s another Amsterdam Java Meetup where we’ll get together and chat a bit about all things Java (and more).

No need to bring your conference mood: there are no sessions, no keynotes, no fireside chats, no breakout rooms. Just some drinks and fellow Java developers.

Also, if you’re not into Java, you’re more than welcome to join.

Be sure to make it in time for the first few rounds, as they’re free. More info on the location, see below.

By the way, if you want to keep up to date about the Java Meetup, subscribe to the Dutch Developer Meetup Google Group.

View Larger Map

Selling Agile Projects Part I – Setting the Stage

April 8th, 2009 by

At JTeam we’ve been doing projects for ages and generally speaking we’ve always done things the agile way. Convincing the customer of the importance of agility and flexibility is something we’ve never found to be a hard sell. How to write this up in a proposal and how to draw up a contract around such an agile project however is rather challenging. In the past, the way we’ve written our proposals and drawn up our contracts has worked reasonably well, but it never hurts to try to improve it in order to satisfy our customers even more.

This is why I’ve been reading up on what others have to say about this subject. What I found was pretty interesting and I’d like to share my findings with you and also reflect a bit on these findings.

Are fixed-price contracts evil?

Generally speaking deals where for a fixed amount of money a project will be executed result in the client having no or little incentive to accept the project as being done or complete. After all, broadening or changing the scope of the project can be done at no cost, since the price has been fixed at the start of the project. The risk is entirely at the supplier side.

Naturally the supplier wants to minimize this risk, so usually demands or forces the customer to be very precise about the scope before the start of the project. In addition he asks for changes to be done using change requests, which subsequently are charged at a certain rate.

In his turn, the customer then puts as many feature in scope as possible, thinking that if he does so, the chances will increase that the features he really needs are among those in scope, hence not needing any change requests.

The end result:

  • Way too many features initially in scope, many of which will be left unused in the end product
  • Too much time and money spent on these features
  • A situation where the customer is encouraged not change his mind too much
  • A situation where the supplier is not encourage to think along with the client during the process as this again results in change

In other words: fixed price deals result in fix bid projects where both budget and scope are tightly controlled and change is kept to a minimum.

We’ve all concluded in the past that agility and flexibility during a project’s execution is something that’s desirable. Given this and the above, fixed price deals are not the way to go if you want agility and flexibility.

So, what is the answer then?!

So if we know that fixed price contracts are not the solution if projects that accommodate change are a desirable thing, what contractual agreement should be used? Well, this is a question not easily answered.

Seth Schubert states things very elegantly in his blog entry on {codesqueeze}:

It is very difficult to arrange a contractual agreement that accommodates change. At the end of the day, your client’s accounting department is going to want to know how much the project will cost, and when they can expect to receive working software.

A bit further on Seth states that

a client will tend to perceive a fixed bid contract as less risky. By controlling the scope and budget in a project, the client’s stake in the project are seemingly protected. The risk of project failure by defining scope to early is not altogether intuitive or obvious.

He talks about the exact risk that we identified above. The risk of implementing too many or useless features, the risk of the supplier not thinking along with the client to prevent him from running into pitfalls, et cetera.

Next, Seth states that:

Even when presented with this information, a new client may still may be unwilling to enter into an open ended contract.

This is what it comes down to: having no prior relationship with the supplier, customers often simply cannot relinquish control over either budget or scope right at the start of a new project. To some extent, I find this completely understandable; after all, how can a customer trust the supplier in his doing the right thing? It’s the first time he’s met the supplier.

Based on this, the question still remains: what contractual agreement makes it possible for the customer to let go of budget or scope in the long term?

There’s in fact plenty of research out there and examples of contractual agreements that facilitate this, some of which I might highlight later on. For now, we’ll first discuss some of the alternative at JTeam and see which ones are suitable for our practice. I’ll report some more of my findings later on.

In the meantime, if you have experiences in this area, you’re obviously more than welcome to share them here :-).