Bas Groot

Before selecting an open source framework definitively, you want to try it out. Last thing you want is build on it and it falls short in production, disappointing users with slowness, bugs or poor usability. A thorough, truly meaningful test is a lot of work that goes to waste again. This article describes a method to do a meaningful framework trial, with a high chance of zero wasted effort.

When selecting open source or closed source frameworks, their marketing is vital information. However, marketing tells you the good news, not the bad news. You need both good and bad information for selection. This article describes how you can distill possible risks and pitfalls by analyzing the marketing, and think like a vendor.

When selecting an open source framework, a main criterion must be how easy it is to get rid of it again later, when it gets obsolete, or just unfit for your new challenges. All frameworks are vendor-locking by nature. There are 7 purposefully designed strategies, to prevent you from ever leaving a vendor's platform; and then you obsolete along with it until your project dies of inertia. This piece explains how to recognize and assess the risks of a "Hotel California", before you check in.

When selecting a framework, examining its API is the first thing an architect or developer should do. This article explains how to examine frameworks methodically and fast, and what specifics to look for, to efficiently judge what the API can tell about the quality and usefulness of each candidate framework.

While a new, cutting-edge open source framework is exciting, there is a risk attached to immaturity. You hoped to get a brand new car, but out on the freeway it turns out it doesn't have brakes yet. This happens a lot in new frameworks. When architects or developers select frameworks, they need to know how mature it is. A project could be stuck or crashing in production until the vendor fixes the bug(s) or unfinished parts; not an enviable situation. With this examination method you can find… Show more

While a new, cutting-edge open source framework is exciting, there is a risk attached to immaturity. You hoped to get a brand new car, but out on the freeway it turns out it doesn't have brakes yet. This happens a lot in new frameworks. When architects or developers select frameworks, they need to know how mature it is. A project could be stuck or crashing in production until the vendor fixes the bug(s) or unfinished parts; not an enviable situation. With this examination method you can find out how mature it really is. Show less

This is a 3-step guide to prevent hackathon code ending up as new production software: developers are often faced with this after the hackathon, and pay a high price for. The article explains how and why that happens, and what an individual developer can do to prevent this; preferably without looking like a bad coder and without killing the fun of a hackathon.

Often developers fix performance problems by starting with the least effective option: caching. This is a practical guide to fixing performance problems in the right order, in 10 steps. Caching should come last. The wrong order is because developers see performance problems as bugs, an unwelcome interruption of work, while many performance problems are rooted in early design decisions and should be solved likewise.

This is a key piece about Agile methodology and how to fix Agile for good.

Unsolved problems are the primary weakness of Agile and should be treated differently. They should be divided in "premature" and "foreseeable" by the architect. They are of different nature. Premature problems can safely be left to mellow, but foreseeable problems must be fixed asap because they get worse over time. The insight in this division can also improve developer-architect collaboration in many ways.

When very successful frameworks and Agile projects are going very fast in the beginning, there is a big risk of Happy Flow Overfocus. Because the happy flow, the "normal behavior" of the program, is the most fun to make, but only 20% of the work. Frameworks typically speed up the happy flow, causing skewed expectations of the "dull 80%" of a project.

A guide into discovering why customers don't say what they want: customers don't know what they want. In Agile projects with their deep customer involvement, this blocks progress. A practical piece for developers to understand why that happens, how customers think and what to do about it.