Software and IT-Project Talk
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.
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.
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".
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:
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 ;)
[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 :)
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. ;)
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 ™.
There's a lot of discussion going on in the software community on "testing". (See for example here, here 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
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.