Business

Homegrown Solutions: Coming back?

I had a quick post over at System Volume. Feel free to read it. Not a lot of added commentary over there, but I think it is an interesting article in light of the economic realities of today.

The past decade brought about a swath of IT outsourcing not just to other countries, but to other vendors. What if there would be pushback against this, a culture shift that aims to bring back in-house IT and development expertise in order to create more nimble companies who can tailor their offerings to the needs of the company? Would this lead to an increase in higher-paying IT jobs here, or would it have the opposite effect by creating, at first, a glut of new positions, leading to a glut of new candidates which would then weaken the overall market?

It is also interesting to think about what this could mean for open source. What if instead of spending money on proprietary vendor solutions, a company would hire a developer and then give back to the open source community those parts which are not business critical? Does centralization always mean higher efficiency?

Lots of questions and I have no answers. It is fun to think about, though.

I would say that I’ve been influenced greatly by companies like 37signals, Apple, and Google, especially in the past five years or so. I like a lot of what Apple has done with computing, and use many of their products in the work that I do. I use Google’s services every day and am using the design updates they just rolled out as inspiration for some of what I am currently working.

However, stumbling upon 37signals through Ruby on Rails thanks to being handed the first edition of Agile Web Development with Rails by one of my coworkers has probably affected me the most in what I have chosen to pursue in my life and how I think about the web, business, and design.

If you want to read a short book to give you a taste of what I am talking about, please check out Getting Real. A major theme of the book (maybe THE theme of the book) I like to sum up as “do less”. Not just building less, but also promising less, hiring less, having less mass (as a company), etc. It permeates a lot of what they talk about in the book and about how they talk about their own company. They released the book in 2006, and even though they’ve grown a lot since then, you can still see them sticking to the major points they make in their book.

However, one thing sometimes lost when people start espousing “doing less” is that doing less isn’t the end of it, you need to do less, better.

This is stuck in my head as I start to flesh out an idea for an application. Do less, better. Cut the scope of the project, do less “checkmarks”. However, what I do, I need to do better. I need to choose a limited number of things and then put all of my effort into making those things work better than anything else out there (where “better” can be a subjective term in certain contexts).

That’s the second part that some people miss. You can’t simply choose to do less, that is the road to failure. You need to take that effort you would have put into checking off boxes and make the stuff that you are doing that much better.

Do less, better.