Wednesday, September 28, 2011

The Yagni Principle


There are a lot of reasons why we do things in software development, not the least of which is that somebody somewhere will find what we're doing somewhat useful which in turn will differentiate us from our competition and earn us money.  Too often, I find developers working on features that 'may be useful in the future,' while the truth is, the fancy code will likely rot before it becomes useful.  Before you write something, think of the possibility that You Ain't Gonna Need It (YAGNI).

Developers can easily come up with shiny new features, but development takes time and resources, introduces risk and complexity and doesn't necessarily add value. Not always does a re-work of architecture to accommodate some future requirement constitute a good idea.  Ideally, a proper architecture would allow us to defer implementation decisions until they are needed without impacting the existing product.

A simple principle of development is to write the simplest thing that could work. I've seen lots of applications and frameworks that do everything imaginable, but usually at the cost of simplicity.

Does this mean that I think we shouldn't plan for future requirements?  Absolutely not. In fact, I would say that all developers should architect in a way that allows for future development, just leave the details for later...when someone asks for them...and is willing to pay for them.

Friday, September 9, 2011

A note on craftsmanship

Considering that the lion's share of software development costs is spent in maintenance, doesn't it make sense that the up-front investment should be spent in making sure that maintenance is as low cost as possible?

Often times we are driven by project timelines and drop-dead dates only to be saddled with a big lump of unmaintainable code.  I've been doing some reading on software craftsmanship and admittedly, some things make you wonder if the tedium of 'extract til you drop' and 'test first' are worth the effort...after all, it seems that some things could potentially double the initial development time.

If 75% of software lifecycle is in maintenance, and 25% is in initial development.  Suppose I double my initial development; if my maintenance is costs are cut in half, then I've saved about 12.5% of my overall cost of development.

25 * 2 + 75 *.5 = 87.5%

If I can reduce my initial development by half, but it doubles my maintenance costs, then it will eventually cost the organization an additional 62.5% more than it had to and as much as 75% more than it would have if I had just spend some more up front time making code maintainable.

25 * .5 + 75 * 2 = 162.5% + 100 - 87.5 = 175%

Easy math for the brass.

Friday, August 5, 2011

Keep your (over)head down

One of the most challenging areas to address when working in an agile environment is managing overhead.

Anyone who has actually read the agile manifesto can tell you that agile favors collaboration over process because process is expensive and time consuming, and in the end, nowhere near as valuable as collaboration.  This doesn't mean that you don't follow a process in your organization, this simply points out that when one of these two elements has to give, it must always be process.

My preference in scrum is one week iterations, especially when the requirements for a project are vague.  The reason for this is because vague requirements equals blurry vision and blurry vision usually equals frequent changes in direction.  I was told recently that the problem with iterations that are too short is that the overhead is too high; by the time you get out of all those planning meetings and demos and scrums, you don't have any time left to do actual work.

The jury is in on shorter iterations, and the verdict is widely accepted.  The obvious solution is to reduce your overhead...starting with much shorter meetings with fewer attendees.  After that, collaboration then becomes a much more intimate, and in my opinion, a more effective experience.

I can tell a team is forming when I frequently see one or more developers standing over the shoulder of another developer looking at his or her screen with two or more sets of index fingers pointing at something on the screen.  I like to refer to these sessions as a huddle; it is where the 'how the heck are we going to do this?' get's done.

I like to try and separate the 'what' from the 'how' during the development process.  The what involves the whole team.  Everybody on the team needs to know what is being done so that they can adjust their actions to best accomplish the goal.  The how is best determined by the ones that are actually doing the work...so long as it fits in with the bigger what that the team is working on.  Planning meetings that include the whole team should focus on what and stay away from how.  In most if not all cases, 80% of the team will not need to know how things are done, and if they do, then they can hook up with the right team members off line to work this out.

Every time I feel like a meeting is dragging on, it is usually because we have gone too deep into the how portion of the topic or worse, complete digression into useless background information.

Aim for:
Daily Scrum - 10 minutes max
Demo - 30 minutes
Sprint planning - 30 minutes
Retrospective - 30 minutes

The tough one here is obviously the 30 minute planning session, some have said that the sprint planning meeting is time-boxed to 4 hours, suit yourself.  Keep in mind that this meeting is to basically create the sprint contract, not solve all the problems that the sprint poses.  Problem solving meetings are best done in the huddle and only with the team members that are actually implementing the solution.  You may have a need to periodically have a more in-depth planning meeting, I suggest every four sprints perhaps do this.

Keep in mind that this is a guide, take as much time as you need, but remember to stick to what and stay away from how.

http://agilesoftwaredevelopment.com/files/Simple_Sprint_Template.pdf
http://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting
http://www.slideshare.net/vickidhiman/what-is-a-sprint-planning-meeting

Friday, July 29, 2011

Keeping out of the weeds

I had the very proud opportunity this year to attend the grade 9 graduation ceremony of my second daughter and watch her deliver a speech to her class about moving forward and not being afraid to make mistakes.  I have to say, it was inspiring to say the least.  What really blew me away was that here was this young lady that I used to hold on my lap and rock to sleep that was now quite possibly inspiring more than a couple of her classmates and helping to shape their futures.

As parents, we take responsibility for our children and tend to take ownership of their bigger mistakes and shake our heads at the smaller ones.  We puff up with pride at their accomplishments, but in truth, it is our children that step up and make the future happen.  My goal as a parent is that one day, my children won't need me, but hopefully will still want me around.

Back in the auditorium, I was hoping that I played some part in inspiring my daughter the way she was inspiring her classmates.  We give guidelines and support, we answer their questions, we challenge them, we cheer for them and we correct them.

What we have to remember is that this is their future an their life, we are just the guides for as long as they need or want us around.

So what does this have to do with technology?

I am hesitant to compare folks I work with to my children, but the common thread is in the approach to helping them succeed.  As a problem solver, my tendency is to jump in and solve problems.  The challenge is to know what types of problems I should be solving.  Too often, managers and leaders are quick to come up with solutions and dictate them to their teams.  Putting aside how right or wrong our solutions may be, this simply doesn't scale and doesn't give room for other bright people to shine.

As a manager, it is far more productive to lead people that can invent on their own and solve problems on their own and simply look to me for definition of riverbanks instead of needing me to pull them through tough the rapids (so to speak).  My job is to watch and listen as they navigate through and make sure that outside perils are kept at bay and not impeding their success.

If you manage people, instead of dictating steps, try setting guidelines.  Instead of solving their problems, try listening and supporting them as they solve their own problems.  Instead of taking credit, give it away.  Instead of pointing fingers, take the responsibility and challenge your team to improve.