Bex Huff says that work-life balance is nearly impossible for good computer geeks. I couldn’t disagree more.

There’s a distinction between creative work that people do for “work” and what they do outside of work. Work/life balance for computer geeks, knowledge workers, or artists has nothing to do with not being creative or solving problems. It’s about giving your brain a break from the same, constant grind and giving yourself time to think and be refreshed.

Like Bex, as a programmer and computer geek, when I go home, I still talk about and think about technology. But that doesn’t mean that I’m still “working.” I may be solving similar types of problems, but I get a lot of relaxation and enjoyment from not working on the same exact problems. Outside of work, I do iPhone development, personal Grails and Groovy projects, AppleScript, play with bayesian algorithms in perl, tinker with embedded linux, spend time with my family, and more. Those are all geeky technology things. But that’s my point - that’s still work/life balance because it gives me a break.

Finally, Bex quotes Isaac Schlueter as saying “An artist doesn’t stop being an artist when he goes home.” It’s true, but that artist doesn’t always work on the same projects when he gets there.

There is plenty to be said for (and against) the new iPhone and all the new apps flooding to our screens but aside from the sluggish response times and occasional crashes, the biggest problem I have is keeping track of and organizing all these apps.

Applications of all types are now spread across multiple screens as I try, mostly in vain, to come up with a strategy that doesn’t leave me needlessly flipping through 3 to 5 pages just to find the thing I want. I have tried to organize them by grouping like apps together on screen but I don’t really want a whole screen for music-related apps or games. Then I tried by frequency of use with the most frequently used apps on the first couple screens and then those I rarely use on the last few. This too was less than ideal as it isn’t readily apparent when I am search for something how many times I really use it. I guess I could try alphabetical.

How about adding folders?

The folder is a simple organizational mechanism that could help keep my applications in order: Creating and naming folders and then dragging apps into them could work nicely. (like shown above)

Double tapping the folders brings up a radial menu of its contents - app icons - that can be clicked. I have mocked up how that may look (see below). A simple, dark overlay similar to a lightbox effect to represent the mode change would work well.

This example only shows a folder with six applications in it and I am uncertain how to deal with folders containing more than eight. Perhaps there would be a number on the the folder and then single tapping would tab through them.

Until I get something like this the number off application I will be downloading will be significantly restrained.

Bonus gripes to Apple:

1. Please let us delete (or at least hide) those app you included on the phone that we do not use. I don’t need stock quotes and notes.

2. When updating an app, don’t move its position. This is very annoying.

3. Get the stability and fluidity of the interface back to the point where it was when the phone first launched. I don’t think you can totally blame the apps being installed, but if you can, then be more stringent on the apps you let in the store.

4. For next iPhone INCREASE THE RAM!

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.

Read the rest of this entry »

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?

This is a little bit older, but pretty interesting: Nine Things Developers Want More Than Money.

It should be inherently obvious, but seeing lists like this every once in a while is a good reminder that creating and maintaining high-performing teams is clearly more about people than it is about process, technology, or anything else.

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]