[french] LE BLOG

Marco Behler's riffs on programming, IT culture and the way software projects are made.

In my last blog post we talked about the different types of software requirements. But how do you generate them, in the first place? What about practical strategies? How do you find out if you are hallucinating or if you really stumbled upon something the masses might want? And how do you find out about those hidden requirements?

In the last blog posts we talked a lot about dissecting requirements. But there was always one silent assumption: That your users and in turn your boss/client more or less all know exactly what they want.

New Book and Oktoberfest Price Deal

Sorry for no new blog posts last month. I was actually busy preparing a new book :) Here’s the news:

5 Simple Ways To Get More Accurate Estimates

Ugh. Your boss wants an estimate for a couple of new features that your client requested. Problem is, your last estimates were way too optimistic and far off the actual time needed. Talk about deadline pressure, eh? Here are 5 simple ways to not make those same estimation mistakes again.

The Customer Requirements book is finally done!

4 common mistakes developers make when estimating

So, your boss asked you to estimate a new feature. You talked a bit about that feature with your teammates. Then came silence. And a brain strain. But after a while you finally came up with your estimate of "ahem...1..to...2..days".

The Anemic User Story

Ever been assigned a user story which looks like this? (Taken almost verbatim from a real life customer project some time ago)

Hot of the press: Customer Requirements EAP!

As promised, the EAP of my new customer requirements book has arrived exactly on time. The first three (very important) chapters are ready!

Another day in the office. Another day of boss-storms-into-the-room-with-a-crazy-feature-request. You don't even properly listen to his actual feature request anymore:

Announcing [E-Book]: Customer Requirements

Do you sometimes feel like strangling your boss or customer because of his vague and ever-changing software requirements?

Too vague. Too broad. Ever-Changing. Hidden. Underestimated. Overestimated. Sounds familiar?

Now we have reached the most dangerous phase when working with requirements. Remember, we started deconstructing our should be really simple login-box requirement.

9:00 AM, your boss storms into the room and says: „Marketing wants a new fancy login box on our website. Just username/password field alright? And maybe a recovery link. Shouldn’t take more than a couple of days. Gotta go, bye!“

In situations like this, you usually scream on the inside. But this time you stay calm. Because you’ve learnt how to deconstruct.

Are you really sure what makes a programmer productive? Is it VIM instead of Emacs, the latest Haskell web framework or your favourite NoSQL database?

Java developers are flooded with a plethora of libraries and tools for their day-to-day work. We compiled a little list of stuff that we use everyday in primarily business line development (CRM, banking, web dev etc.) and that we can wholeheartedly recommend. There’s also a very opinionated section of people that we’d like to give some props to, if you are not on it, give us a shout ;)

Should you test your ORM mappings?

Welcome back from the summer pause!

[this is actually a post from our mailing list from a month ago. if you are not yet a member, devour it and sign up at the bottom! :) ]

Sooner or later in the lifetime of every actively developed code base one reaches the point where it seems to get harder to iterate. Features take longer to be implemented, short-cuts taken in the past rear their ugly head etc. This phenomena is so common that we techies gave it a catchy name. We call that technical debt.

This post was originally titled "jOOQ : The good (and bad)". But we noticed we not only wanted to talk about jOOQ, but also put it into the bigger picture of the Java persistence landscape. Hence, quite a few words about JPA/Hibernate. As a result, you, the reader, will get a nice comparison of the two. Note: Take this post with a bit of humor :)

Should my tests be @Transactional?

Simple question. The simplest answer to that may be "It depends.".

IT projects, especially medium-to-large sized ones sometimes just feel like house moving projects..Enjoy! :)

Last time in our "Speed Up That Build, now!" propaganda series we tried to show a specific approach using a ram disk to speed up a given build. This time we try to generalize our ideas to give you some additional options on the file system choice. As an added bonus we even try to do proper benchmarking this time. ;)

Maven: Don't just blindly "mvn clean install"

Suppose you have a multi-module Maven project, with a ton of modules, two of them being fancynewtool-db and fancynewtool-rest. fancynewtool-rest has fancynewtool-db as a dependency. What happens if you cd into the rest-module and do a mvn clean compile/test for the first time? Maven will tell you that it cannot resolve the db-module dependency. And now your instinct might be to do a blind mvn clean install in the parent project, because that is just the way Maven works ™.

An intro: How do I test my software?

There's a lot of discussion going on in the software community on "testing". (See for example herehere and here). We think there's too many superstitions and assumptions. Very little of this helps in your day-to-day work and leaves you still wondering how you reliably and automatically test, for example, that crazy sql query, your UI or that complex batch job.

Update: As reddit commenter flussence pointed out our numbers here aren't very reliable. So if you want to compare things some may suggest that running

sync; echo 3 > /proc/sys/vm/drop_caches
before each time taking is a must. What we aimed for in this article though is to show two simple ways of speeding up an arbitrary build. Whether our suggestions are applicable to your given use case is something you have to see for yourself.

Are you also dreading your slow CI jobs? A build+test cycle of a couple of minutes sounds like a far distant dream. Reality is, after each check-in you can grab a coffee and watch the first half of the Godfather until your test results trickle in from Teamcity or Jenkins.

Older Posts