Nat Pryce has compiled a list of Laws of Software Development (and an addendum). I hadn’t seen all of them before, but I enjoyed the entire list. Some of my personal favorites:

Brooks’ Law

… adding manpower to a late software project makes it later.

The Cardinal Fundamental Law of Programming

It’s harder to read code than to write it.

And here are some that are perfect reminders for why agile methods are a good idea:

Hartree’s Law

The time from now until the completion of the project tends to become constant.

Hofstadter’s Law

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Lehman’s Law of Continuing Change

A program that is used in a real-world environment must change, or become progressively less useful in that environment.

Lehman’s Law of Increasing Complexity

As a program evolves, it becomes more complex, and extra resources are needed to preserve and simplify its structure.

The Ninety/Ninety Rule

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

There’s a lot of good stuff in there. Be sure to check out his full list.

At Refactr we don’t often get RFP’s (Requests for Proposals). Most of our consulting project work comes from word of mouth and referral where we help brainstorm what is to be created at the outset. It is the only time in a project where there are routinely meetings for more than an hour - a time of much personal interaction. I would say that sending out an RFP, sends an entirely different message. At best, it is impersonal and puts up walls that must be knocked down. More seriously, when it comes to software development projects at least, RFP’s can set the stage for failure.

An RFP attempts to describe and document the project. The first part of this (to describe) is good, but the intent for an RFP to do anything other than get some ideas down and start a dialog between the stakeholders and developers* is misguided. An RFP is drafted prior to development, when the least amount of information is available and with a small subset of the whole team in place.

Another side-effect of the RFP process is the creation of a mindset that software development is something that happens to an organization by an external source. Software development should be one of the most collaborative endeavors into which businesses enter. Stakeholders and developers should work side-by-side in designing the software, customers and those who use the software should be involved in the use-and-feedback loop.

To underscore the idea that RFP’s are simply the “hello” to a longer conversation, we often informalize the process right up front by meeting in person and responding with text emails rather than fancy Word or PDF file proposals. Our hope is that this helps to establish a new tone for the project and have found that when formality dissolves away, real communication happens.

* The terms developers and software developers are used here to encompass all people who develop software including visual, information, and interaction designers, client-side coders, server-side programmers, etc. I could also have used software designers to mean the same bunch of folks.

Lean-to is live! We haven’t done a great job of keeping the work we have been doing under wraps but we haven’t been promoting it either. Since we gave a demo of our agile project tracking application, Lean-to, at minnebar in May, we have been adding features and tweaking it until we were ready to start talking about it.

We wanted to let everyone know that we have pushed out some significant updates to Lean-to that we hope will get people excited. Here are a few of the highlights:

• Add people to your account and manage settings
• View plan and backlog views for your stories/bugs
• Track team progress with report views
• Get more info on list views with new context menus
• Add tests to stories in improved ways
• Assign stories or bugs to iterations from the backlog view
• Filter lists to show only those stories or bugs assigned to you
• More invite and project options
• Various interface improvements

We hope that you enjoy the new changes in this release and we ask that you don’t hesitate to use the feedback link to let us know what you like and don’t like about Lean-to.  We’ve got lots more on our own backlog, but we’d love to hear what you want from Lean-to.

(more…)

I personally haven’t heard this question before, but Martin Fowler mentions that he has been asked whether a team should use agile development or lean development for a project. The answer is that they’re not alternatives.

Lean development is a type of agile development.

In fact, Mary and Tom Poppendieck title their book “Lean Software Development: An Agile Toolkit.” And the introduction describes the book as a set of thinking tools for translating lean principles into effective agile practices.

In his post, Martin refers to Richard Durnall’s thoughts on using lean principles with agile projects, which I also enjoyed.

The better question is, how many lean principles are appropriate to implement for this project?

Much has been written in blogs and in the news media about Best Buy’s Results Only Work Environment (ROWE). And while the idea (do whatever you want, work however you like, as long as you get your work done.) is cool and it is nice to see a big company embracing some agile ideas, this is not a post about ROWE*.

As a follow-up to my post earlier this week, I wanted to post some pertinent bits of a recent discussion I had with Geek Squad founder and current Best Buy executive, Robert Stephens. He is implementing a plan to “think small” from inside the behemoth that is Best Buy. Stephens’ plan addresses each of the points that Mike Speiser of laserlike.com concludes are important advantages that startups have over large organizations in terms of innovation, namely: the investment model, incentives, and risk taking.

His idea would focus on technology and software solutions developed by small teams or individuals within Best Buy (or failing that, using small teams or individuals from the outside). The first step would be to create an infrastructure that allows for projects to get up and running with very limited administrative or technical setup. Once a problem or opportunity is identified, employees are encouraged to bid for the opportunity to tackle a problem by offering up their solution and what it would take in terms of time and money. The best ideas are funded (in the form of a bonus) or, in some cases, combined into teams. We aren’t talking about large “corporate-type” budgets either - these could be a couple thousand to twenty thousand dollar budgets. The goal is to side-step the typical flow of events in corporate business: get an idea, meetings and discussion, document the idea and discussions, sending the idea “up the flagpole”, having more meetings, having the idea morph, incorporate additional ideas, and finally either get the “green light” or be canceled weeks, if not months after the solution would have ideally been implemented.

This concept allows Best Buy to act like a startup in all the ways that are important. It allows for “distributing investment and other decisions” (a new investment model) across the organization allowing for risk-taking by individuals who are incetivized by the ability to create something great and get paid extra for their efforts.

* For more on ROWE, check out this Tim Ferris post for more on ROWE or the blog of ROWE instigators Cali Ressler and Jodi Thompson.

One of the best parts of Minnesota’s barcamp, minnēbar this year was the panel discussion on the state of technology in Minnesota. During the discussion everyone got the chance to hear from and ask questions of some leaders in the Minnesota tech and business communities, including: Doug Olson (Founder of Authorware, led the development of Adobe ImageReady, and now starting a Microsoft office here in Minneapolis), Jamie Thinglestad (Former CTO of Dow Jones MarketWatch, and 2008 Business Journal “40 under 40″ award recipient), Michael Gorman (Co-founder of venture capital firm Split Rock Partners), Robert Stephens (Founder of the GeekSquad), Dan Grigsby (2008 Business Journal “40 under 40″ award ), Matthew Dornquast (Co-founder of code42 Software).

A large portion of the talk was comparing the environment in Minnesota with those on the coasts in terms of entrepreneurial spirit, startups, and venture money with a good deal of discussion mirroring Dan Grigsby’s post titled A Plan For Minnesota. The consensus seems to be that our tech start-up community isn’t thriving,  not for lack of access to great people or ideas (or even money though I think that’s debatable) but rather for lack of guts.

It definitely takes guts to leave a nice salaried job where, frankly the expectations for you are set pretty low. Big banks, insurance companies, and even tech-focused companies rarely can sustain the culture and spirit that got them there. The sheer size of the machine becomes so large that innovation and personal accountability shrink into the shadows. Despite billions of dollars spent on research inside Microsoft, Oracle, Yahoo, and yes even Google, all too often the game-changing innovations are created by small, hungry companies who then get purchased.

Venture capitalist, Mike Speiser over at laserlike.com has some great insights on this. He looks at the 2007 R&D investments at 3 major companies (Microsoft: $7.1 billion, Google: $2.1 billion, Yahoo: $1.1 billion) and then the $5.1 billion VC’s put into startups and makes some observations:

My strong suspicion is that the return earned by investors on that $5.1 billion (in aggregate) will exceed the returns on the $10 billion (in aggregate).  If you buy this argument, then there is only one logical conclusion. There isn’t too much money in venture, but rather there are too many good people in large firms.

He states that startups are the right place for innovation for these three reasons (I am paraphrasing here):

1.  The investment model - Big companies often won’t kill bad projects where small companies must. Startups are more practical and results oriented in what they prioritize. Centralized knowledge and limited employee ownership/investment hinders large organizations. Large firms should create a system for distributing investment and other decisions.

2.  Incentives - Paying for performance is easier in small companies. The probability of success equals the number of experiments per invested dollar times the number of dollars.

3. Risk taking - In big companies perceived risk curtails innovation and agility. This must be overcome.

There is a positive selection bias in startups towards an appetite for risk.  People have “overcome” their fear — at least enough to be at a startup.  When you have an entire group of people who have overcome their fear, you get positive feedback.  People egg each other on to break the rules.  To “think different.”  To be open minded.  That sets off a cycle that drives people to throttle risk up and up and…

As much of the panel at minnēbar concluded, it is this last point that they believe is holding Minnesota back as a hotbed for technology startups. Minnesotans are hard workers but for whatever reason, are more risk averse than their coastal brethren.

Here’s the coolest utility I’ve seen in a while: OS X Trash. It allows you to manipulate the Trash from the command line; trash files, list the contents, and empty it all from the command line. I’m actually wondering if I might want to try aliasing rm for this. I’ve known the horror of accidentally rm -rfing the wrong directory…

[via Daring Fireball]

I put the slides (with notes) from my MinneBar presentation on iPhone development up here. I hope everyone enjoyed the presentation; add a comment or send us an email if you have any questions. Lastly, if you’ve got an iPhone app that you want developed, don’t hesitate to ask us! You can find Ben and Scott’s slides here.

Shawn Hartsock has written an in-depth post on writing a Grails plugin to do audit logging. The post is great on several levels. First, he gives a good introduction to just how easy it is to write a plugin in Grails (mostly because a plugin is just a regular old Grails project with one extra file). The second level of awesomeness is that I’ve really needed audit logging and hadn’t dug into it myself, so by seeing this I’ve gotten out of work and you can’t beat that. Thanks Shawn!