28 Apr 2010
We’re looking for a few talented developers to join our ranks.
GenoLogics is a leading provider of lab informatics solutions for translational research, with solutions crossing the clinical and discovery domains. GenoLogics focuses on providing best-in-class informatics solutions for genomics/next generation sequencing, proteomics, and biorepositories.
Traditionally we’re a strong Java / Groovy shop, so if the thought of living and working in lovely *Victoria, British Columbia *appeals to you. Let’s get in touch.
Relocation costs would likely be discussed if you’re an out of towner (Seattle, Calgary, etc.)
You can reach me at: adam.jordens** –at- **genologics –dot- com
More information on the jobs themselves can be found here
04 Mar 2010
I was fortunate enough to recently have my 3 year old MacBook Pro retired from service. A new and much faster one has appeared in its place.
Old Laptop (2.333ghz, 5400rpm HD, 3GB DDR2)
mvn clean install – 8-10 minutes depending on system load
mvn clean install -DskipTests – 4-5 minutes depending on system load
JBoss startup – 70-90 seconds depending on system load
IntelliJ Responsiveness – Slow
**
**
New Laptop (2.8ghz, 128GB SSD, 4GB DDR3)
mvn clean install – 3 – 4 minutes
mvn clean install -DskipTests – 70 seconds
JBoss startup – 32 seconds
IntelliJ Responsiveness – Blazing Fast
Night and day difference. I haven’t counted yet, but on average, I would anticipate doing probably between 8 and 12 build + deploys a day. A realistic estimate would put my daily build time savings around 30 minutes. And that’s discounting the morale and efficiency boost coming from not having to context switch every time the machine bogs down because something is running in the background.
I’m a developer and speed geek. I’m that guy who grew up with the 300A Celeron overclocked to 450mhz. I’m greatly annoyed with inefficiencies and constantly find myself tweaking aliases, just to get that 5 step build process down to one.
**
**
Fuzzy Math
Assuming a pie in the sky daily wage of $300 (to make the numbers easier), a 30 minute savings per day equates to $18.75. Multiply that by 250 days worked in a typical year (2000 hrs) and you’re looking at a theoretical productivity gain of over $4500.
I would argue that regardless of how efficient you think your programmers are today, you will always see positive benefits from ensuring they always have access to decent hardware and build environments.
Now take this new laptop. It cost under $3000 (apple premium). If laptops aren’t your thing, a desktop can be had probably half.
If you cannot justify spending $3000 per developer every 1.5years, at least consider upgrading core components. I don’t have numbers, but I’m guessing that a significant portion of the improvements I’m seeing were a result of the SSD.
Either way, if you value the time of your programmers, I don’t see how you can lose.
Time is money, and efficient programmers == happy programmers.
01 Mar 2010
The act of writing good software is as much process execution as it is source code generation. Follow the right process and it can be a tremendously enjoyable experience.
There’s nothing I like better than to come home from a day in the office and marvel at the amount of work accomplished (easily measured as tasks completed, bugs squashed, etc.). See that burn down chart trending downwards can bring a tear to a man’s eye!
Working hard is not what burns me out, it’s the soul sucking meetings and status updates along the way.
As a working example, I’m going to outline the high level processes, tools and techniques that my team and I regularly follow during our quest to develop good software and get it into the hands of our customers.
First, I’ll quickly outline the various tools that are used to make our collective lives much easier.
Tools
We are huge believers in the entire Atlassian stack. We started out with JIRA five or six years ago, and our tool box has expanded to include Confluence, Fisheye, Crucible, Bamboo and most recently GreenHopper.
If you’re a development shop (of any size really) looking for a kick ass suite of tools, look no further than what Atlassian has to offer.
For the purpose of this post, I’m going to focus on JIRA/GreenHopper, Crucible and Bamboo.
JIRA is a typical bug tracking software, GreenHopper is a set of agile extensions that allow you to easily manage and prioritize User Stories, Tasks, Bugs, etc., visualize burn downs, and manage sprints/releases on a per-project basis.
Every single piece of work we work on is estimated and tracked in GreenHopper. Burn downs are generated automatically and actively monitored. Prior to GreenHopper, we were manually tracking cards on a whiteboard and generating burn downs through Excel. Very cumbersome. I don’t even want to remind anyone of what happens when someone knocks all the cards off your whiteboard.
Crucible is essentially online code reviews done right. Simply point it a repository (subversion in our case) and you can completely manage the peer review process through a web browser. Prior to moving to the online review process, we were doing over the shoulder reviews prior to check-in. This required someone to drop whatever it was they were doing, and head over to your desk for 15-20 minutes. With Crucible, code is committed first and reviews setup immediately after. You can easily track what code has been reviewed and what hasn’t.
Bamboo is the last piece of our puzzle and manages all of our continuous integration builds. We have a series of builds that are either run per check-in or nightly. Performance reports are generated and published to a Maven site nightly.
Process
For the past two years we’ve been developing software in effectively two week chunks with a release every month.
Each two week iteration starts on a Wednesday and consists of the following:
- A 1hr kick-off and retrospective meeting
- Daily 10 minute scrums with members of Development and QA.
- A 1hr sync. session with Product Management every Thursday to quickly review progress and have any outstanding questions answered.
- An all hands on deck 2hr test session every second Thursday. This includes members of Development, QA and Product Management.
- A 15 minute show & tell every second Tuesday (last day of the iteration) with members of Development, QA, Product Management and Technical Writing.
Ignoring the scrums, that amounts to < 5hrs of meetings an iteration. Sounds simple right?
All of our kick-off meetings involve a review of our backlog and upcoming iteration. The backlog is a JIRA version that theoretically contains all the user stories, tasks, bugs, and anything that we could possibly work on. It’s prioritization is a collective effort by both Development and Product Management. Items in the backlog may or may not be estimated, and each 2 week iteration includes roughly 1-1.5 weeks of estimated work per developer. This 1-1.5 dev weeks / iteration / developer is essentially our velocity and can be adjusted to account for risk and granularity of tasks being worked on.
Once tasks are pulled into an iteration, they must be (re)estimated (typical granularity is 1-3 days). Design is a considered a critical task and it’s not uncommon to see dedicated design and review tasks in our iterations.
At the end of each iteration we run a retrospective. This gives us an opportunity to review velocity from the previous two weeks, as well as identify things that we did well as a team and things we would like to improve upon. We identify 2-3 items from the list to focus on for the next iteration.
Every morning we kick off the day with a quick 10 minute scrum. This scrum provides each member of the team with an opportunity to highlight what they’ve worked on in the last day and identify any blockers to the group. Depending on whether or not everyone is in the office, we may choose to run this in-person or via Jabber/XMPP.
Once a week we take an opportunity to sit down with Product Management and review our backlog. We’ll take a stab at estimating the highest priority items and may even move them into a coming iteration / release. We typically only plan an iteration or two into the future.
Finally, to end of an iteration we have an all hands on deck test day on the last Thursday. This involves all members of development, our QA representative, and at least one person from Product Management. We prepare our test cases ahead of time and take over a board room for 2 hours. It’s important to get everyone in the same room in order to make efficient use of time. Questions must be answered quickly, and it’s important to have representation from both Development and Products.
Throughout an iteration we will do frequent deployments for other people in the organization to play with. With only one technical writer for the whole company, it’s been a difficult haul to keep user facing documentation up to date with each release. In addition to documenting the expected and actual behaviours as part of User Stories, we’ve started doing quick 20 minute show & tells on the last day of an iteration. This gives the technical writer and product management one last opportunity to review features before the iteration is closed and the release goes out the door.
Assuming everything goes to plan, we close everything down on a Tuesday and prepare ourselves to start fresh on the Wednesday. It’s important to note that we purposely start and end our iterations mid-week. We found the stress level to be significantly higher when we attempted to rush for a Friday completion date.
That’s it in a nutshell. We’ve been following this basic process for the last year or so with a decent amount of success. Of course nothing is perfect and we’ve made minor modifications as necessary.
I’d be interested to hear what others are doing for a lightweight agile process and what forms of tooling they’ve incorporated.
Cheers!