Thoughts for Thursday: Go for a walk!

Clinical studies have shown that walking can have numerous benefits to your health, depression and well being. It can boost your weight loss, ease depression and enhance your life.

We have the duck pond like in the photo above by my office and just about once or twice a day, me and some buddies will walk around the pond and watch the geese or just enjoy the peacefulness of the pond.

Photo by Fernando Begay

Thoughts for Thursday: Use Noise canceling headphones

I recently bought a pair of the Audio-Technica ATH-ANC7B from Amazon. They’re close to $100 but they’re less then the price of similar Bose headphones.

These headphones are awesome. It’s active noise canceling so it cancels out white noise. You have no idea what kind of white noise is in your environment until you put one of these things on and turn it on. It’s amazing! There is no more noise. You can still hear people talk in a muted sense but oh man, these things are awesome.

Once they’re on, put on some soft music and you’re in business for concentration for hours. The only downside is my ears are a little big, so the lobes hurt after about an hour or so. Thats ok by me.

Scrum is the new waterfall

Scrum while great in theory is in practice a really flawed process of creating software. Scrum is iterative waterfall. Scrum is process hell. Saying this, may get me shunned and kicked out of the Agile club. But I really believe that the bane of our industry is the process management called “Scrum”.

Scrum is Agile

No it’s not Agile. Scrum is anti Agile. It calls itself a Agile approach or methodology but if you read the Agile manifesto scrum by that definition is never going to be Agile. The process of Agile is the prioritizes people and interactions over processes and tools.

Scrum has many “ceremonies”, it feels like going to grandma’s old church services where the people repeat what the “Scrum master” says, listen to the ideas put forth in “Sprint Planning”, “Grooming”, “Stand up” etc.. It’s boring, its old, it leads to pointless meetings run by people who don’t write software, who don’t understand the technical process behind writing software and don’t always care.

Adhere to the sprint commitment, even if you have to work over time. You committed so you have to deliver. Since when did a human ever estimate something accurately. We can’t even do this when building sky scrapers, let alone a  5 million dollar software project.

How to be Agile

Accept that Agile is about people first and foremost. What will move you quickest to the goal? Be pragmatic. Don’t waste time on pointless meetings like planning or grooming if that’s not what will allow us to move faster.

Use standups for what they’re designed for, they’re not for updating your status to your managers. It’s about quickly getting the team unblocked and moving fast. Stop meeting everyday at 9 am. Start meeting many times a day, if there’s a blocker, get the people you need in a room, stand up and unblock the thing you are working on.

Agile is about moving fast, building working software today and delivering with changing requirements. Scrum can’t change without process during the sprint cycle, this inhibits your ability to change and move faster. What if yesterday the requirements were X and today now they’re X and Y? What if you can deliver both today rather then next sprint? Doing it today might be better then next sprint .

Move faster

You need to write tests. Does the UI render and do its thing correctly in all happy paths? What happens when the data is bad? Test your APIs, do they contain the right contracts, ensure that they are returning the correctly formatted and designed data and that they contain correct data. Test performance and security.

Can you ship what’s on Master right now? If not you have a lot of work to do. Master should always be ready to go to production. If you can’t, you’re not Agile.

Writing tests reduces risk, If you refactor or redesign you can ensure that the system won’t break.

Screw unit tests, test the contracts

I bet you 90% of the time your code isn’t doing something totally unique like calculating the cost of a family of 5 with disabilities and all kinds of heart issues. Test where it makes sense, unit tests can be great but they tightly couple your tests to your code, making it really fragile and anti Agile.

This is where contract testing comes in. Test the contracts between classes, what is the public interface? Ensure this always does something sane even with bad data. Test the API contracts! Ensure the API returns valid data, validate with a JSON schema or an XML WISDAL or whatever schema you can get for your API.

Test UI contracts. Whats the main success scenario? What is the common path, Test functionality, not design or placement.

If you have to, use Kanban

I think most processes are a waste of time expect Kanban. Have a few simple columns:

  • Undefined — Someone needs to add details
  • Defined — We think we have enough details to work on it
  • Working on it — A developer is working on it
  • Done — Its done and ready for approval from the creator
  • Approved — this isn’t a column but a state, when it’s done, it’s off the board.

A card doesn’t have enough details! So ship it back to undefined or get out your chair and talk to the person who wrote it!

It has no task hours: Humans suck at estimating. Instead log actual hours if this is a important metric (ex: consulting company).

Photo by William Warby

Thoughts for Thursday: Have some sample code

Code is like a living resume. You are constantly changing and learning, or at least I hope you are. If you’re a developer, you may never know when you might be out of a job, so just like it’s a great idea to keep your resume up to date, I highly recommend keeping some sample code around.

I don’t know how many times I get asked by a recruiter every time I go looking for a job if I have any samples. The answer is always no, and often I get passed up for the guy who does have code and contributes to open source.

But I don’t have time?– I used to think that, but after a couple of coding interviews, I took their ideas, things like a color picker and composed my own github repo containing samples I’d be proud to put my name on.

You don’t have to update very often, I would build a couple of demo apps. Stuff that you’d be proud to say, “I did this”. It could be a simple color picker in HTML 5 and Javascript, or it could be a Todo List application in Rails and SQLlite with Rspec tests. Try to show the picture of, if you paid me, here’s what I could deliver.

Ashley Madison: The use case for general encryption

Encryption really isn’t the sexiest topic, certainly not as interesting or thrilling as something like Ashley Madison, a site that promises you discrete encounters no matter your marital status.

Their entire premise is “Life is short. Have an affair!”. This presents a general use case that we as web developers must look at more closely. Encryption for the web isn’t just for passwords any more. It really should be about EVERYTHING else, because the “devil is in the details”. Continue reading Ashley Madison: The use case for general encryption

Thoughts for Thursday: Why I wouldn’t use Rails for a new company

Jared Friedman recently wrote a really great article on why he wouldn’t use Rails for any new company. There are a couple of factors that he looks at that makes this a really well written article.

First, he uses data to show the rapid decline in Rails usage by looking at Google Trends. Then he looks at Rails biggest performance headache: ruby. He compares benchmarks of Ruby to other languages. He points out that Ruby has no major corporate sponsor. He also points out the newer growing frameworks around and the job trends on Indeed.

This is a really good article, I would encourage you to check it out and read the Hacker News comments too.

Photo by Adam Bourg, screenshot of

Write better specs!

I love RSpec. It’s one of the best tools on the web for opensource developers to write tests. Nothing compares to its power, ability and extensibility. Mocha and Chai for Javascript pale in comparison to its ability to test.

That said there are some really terrible spec files out there. I’m wholly grateful for a resource you all must checkout if you write Ruby or RSpec, its called “BetterSpecs”. Its a online resource containing examples of bad ideas and examples of better ideas and finally examples of best practices to use when writing RSpec tests.

Check it out, it’s totally free: 

Thoughts for Thursday: Lazy rebasing

Rebasing is extremely useful, lets say you branched off of release 1.8.3 and need to fix a defect, but it wasn’t completed until 1.8.3 was already on production and 1.8.4 is the new hotness. git rebase release1.8.4 defectBranchName will take defectBranchName and reapply the commits over release1.8.4’s history instead of what it was originally based off of.

The problem is if there are conflicts and sometimes there can be conflicts at every commit. So if possible, what I do is:

git checkout defectBranchName
git log

At git log, count the number of commits you made on the branch, N = number of commits to go back

git reset HEAD~N –soft
git stash
git rebase release1.8.4
git stash apply

Now you fix the merge conflicts, and commit. The downside is you lose commit history and can create issues if you do this on something like master because you’ll be changing history. It’ll be especially big impact if you work on a team and do this on develop or master, but your little feature branch should be ok if no branched off it.

Now there you go, a handy little trick to quickly get synced up with history!

Photo by heipei