2015/05/03

Almost 2 years later: FailFast v. 1.0 released

Waz dhis 'bout?

My previous post - http://starkcoder.blogspot.dk/2013/06/how-could-failfast-library-work.html - was an idea to a simple and easy to use failfast library design. Here almost 2 years later that idea - and some more - has been turned into a JAVA library. Whether it useful is really up to you to decide. If you want to know more about the library (and I hope you do) go have a look: https://github.com/KeldOelykke/FailFast. This post, however, is about the process of making such an open source library.

A Need was building up

"Wouldn't is be cool if..." and "all we then had to do" but "sounds simple but I don't think we have the time right now". Sounds familiar?
There seldom is a paid project where you can go all in on something so basic as a failfast library. The reality is that we do some assert methods on the fly in a central or abstract class... and that is it. The next project we might make a copy ... or might just as well write a new one.
This is kind of silly, since failfast is a relative important matter. One may argue that failfast is just as important as logging. Why is it then we have multiple logging libraries but no failfast library?

The Idea

Some experience with a team resulted in what I ended up calling the spot contractor software pattern - http://yoawsconsult.blogspot.dk/2012/11/spot-contractor-software-pattern.html. It was pretty natural that this pattern would be the core of failfast library, why it was used - without any presentation - in the previous post - http://starkcoder.blogspot.dk/2013/06/how-could-failfast-library-work.html.
It is still a mystery to me why this enforced approach is not used in every logging or performance measurement framework.

The Job Change

It took almost a year for me to go from the Idea to the beginning of the library. The first commit was 5th of May 2014 - https://github.com/KeldOelykke/FailFast/commit/177d979e0ce4fee03c252b74091f0a50b695bdc5. The reason was a job change 1st of January 2014.
I did that job change with an awareness about the Idea, so I could enable it without asking anyone for permission.
If you are a developer don't ever sign a contract that gives the Employer all rights to software that you create during your employment. This is almost an industry default phrase in contracts, but you need to ask for it to be more specific (work related in some manner). Otherwise, who owns the right to your spare time software? and is it at all possible for you to make software open source?
If you are hiring a developer it may be that you would love to hire a developer that has experience from the open source community. That probably will not happen, if you won't let developer stay in open source community.
With all intellectual property obstacles away, I could start coding.

Commit yourself often

My poison is playing League of Legends - http://leagueoflegends.wikia.com/wiki/League_of_Legends. It is in so many ways right. So how does my hobby coding project compete with a game of LoL? For every X hours of LoL it is reasonable to spend Y hours on my hobby. You probably know this deal from exams or similar. X/Y is kind of a trade factor for your motivation. It doesn't really matter what X and Y are or what you poison is. What matters is that your motivation for the hobby project is acknowledged by you (and your spouse).
In practice I usually use Monday (and/or Sunday) evening on my hobby project - https://github.com/KeldOelykke/FailFast/graphs/punch-card.

Get your code into a form

Like a kid I like when things gets repeated. It gives me sense of normality. If every piece of code I open is unique in some way, my pattern recognition says no. I know when coding is getting repetitive the design is somewhat stable. The amount of the next X features is getting predictable. All is good.
For the FailFast library the form is the usual co-operation between the 3 main classes - Checker, Failer and CallContractor, it is the check-fail interface pairs that defines a feature, it is each unit test, etc. The form is so important for the next commit, because it takes much less time the better form your code has.

Define 2 major milestones

This is where you scope your 1st release. You need the 1st reason to celebrate - the 1st release. To get to that 1st release you have to push some features to a future release. That is why you need a 2nd milestone. It is a dump for your thoughts and ideas. It may be that the next major milestone has a theme that you plan for - that is a great way to group some features that you needed out of your first major milestone.

Many minor milestones - because you can

You are the Boss. Whatever you feel like cool improvements - make them. This is your work paying of for you. Your hobby project motivation is rising and your library gets worth. Embrace an idea for improvement with a minor version release.

Users where art Thou?

I wish I could tell you something clever here, but the Truth is that I need Users. I that you?
  • No? Why not? 
  • Maybe? Great let me know what you need to get started? 
  • Yes? Super. You might be the first. I would love to hear you thoughts and experience.
In any case Thank You for reading this post.