no, really

Here it comes - the requisite position statement and analysis of crowdsourcing. It’s a little late - I didn’t ride that trend wave back when the scandal over the paying of select members of the crowd to do their thing broke. I was inspired by an article in “strategy + business” that talks about the parallel topic of crowds and open source software.

(more…)

As I mentioned previously, I’ve been cooking up a lot of new stuff this summer. I’m really kicking things into gear and putting in a lot of extra effort to push myself into doing what I really enjoy, and what I’m the best at. Specialization is tricky, and almost seems silly at a time when there is a lack of programmers out there!

After a lot of careful thought, and some talking it over with colleagues, I’m moving my services into a more architecture based area. I’ve always had a strong analytical bent to my thinking, which is why I’ve been so successful in my field. All of the terrific work I’ve done I would attribute to the thinking that came before it.

For the time being, I’m doing mostly what I’ve been doing in the past - programming. I’m fortunate enough at MetaFoundry to have the opportunity to shift a lot of my tasks into this new set of activities. Troy is both accommodating and appreciative of my new specialization in that regard.

You can check out what I’m talking about by poking over in the Services section in the sidebar. The people that I think would benefit from this kind of work the most are startups who are short on tech managers, and agencies that are more design centric. I’ve also got end-to-end experience with large, long-term projects within medium sized businesses. Pricing for the different services varies, and as things get going, I’ll set up a flat-rate fee structure for a few of the consultation activities to make it more accessible.

This is just the beginning. For now, my blog is a decent host. I’m working on a new name and site that will feature testimonials and resources for development, as well as an easy way to contact me.

ps. I must be serious if I’m working on this during a sunny summer Saturday!

As you can see, I messed around with my template a little.  I was getting bored with that default template, so I messed around a little.  It’s not exactly fancy, but it’s mine for now.  I’m sure I’ll muck with it as time goes on.

A little bit of news on one of the projects I was working on: Silicon Alley Insider has officially launched as of last Friday!  How exciting…  It reports on all things tech in the world, and more specifically New York.   There are still a few quirks to work out - mostly a result of the medium - but the content is great!

Meanwhile, we’re still searching for a developer for Noo.  I’m going to be honest - we’re not looking to be fly-by-night and blow up in users or make billions on advertising or anything cliché like that.  It’s a sustainable business model that is likely to turn into a really solid, profitable business.  It’s always good to get in on the ground floor of those.  Plus, we’re nice guys

I’m sure I’ve written about this in the past somewhere… buried in my posts. For the sake of emphasis, I suppose, I’ll write about it again.

Last night I sat down with Troy to talk about all the stuff you never get to talk about in meetings. Some of it was personal, some of it was business, some of it was my personal thoughts on his business. One of the big topics, which was an extension of a discussion that started in a production meeting a few weeks back, had to do with people wearing different hats in the organization.

I’m all for cross-functional team members when it comes to a very entrepreneurial boutique firm like MetaFoundry. We’re all really skilled and talented, and have interests in different fields, and are capable of doing great things in different areas. For example… I may be asked to do the db design on one project, and squeak out a few scripts on another, while participating in the discovery for a third. A designer might fiddle around with the CSS for a site to get it to do what they picture in their head.

One of the lines that I think is difficult to cross is the one that exists between the “supporters” and the “creators.” The creators are an eccentric bunch. At least the good ones are. They’re responsible for delivering great work to the people that request it. That can be any number of things from reports to software to pamphlets, etc. The supporter’s job is to make sure that all the creator has to do is create. No worrying about clients, scheduling, resources, lighting, etc… just create.

This can also be described as Joel Spolsky’s Development Abstraction Layer:
“With a software company, the first priority of management needs to be creating that abstraction for the programmers.

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.”

It’s worth reading a couple times, but the point is pretty clear. In order for those creative (and therefore temperamental) creators to do what they do so well, they shouldn’t have to worry about stuff. Have you met many programmers that were good at project managing themselves?

What’s always the challenge is applying these idealistic concepts to a tiny, shoestring organization. I enjoy doing this: taking abstract concepts and figuring out how to make them work in real-world situations. It’s pretty much my job on a fundamental level. I’ve done it before with some other development concepts (I’ll be sure to talk about soon ), and this support/creative balance is at the core of it.

The glue that keeps these two halves together is process.  There are a few buzz terms in development that chastise the overuse of process, or extol the virtues of rigid processes.  The one that I always try to keep in mind is “people over process.”  In the end, a process is meant to *help* the people, and if it doesn’t, then it doesn’t serve a purpose.  If you can’t come up with a simple, easily justifiable reason for how a process helps someone, then it’s likely that it’s unnecessary.

On the flip side of that coin, a lot of day-to-day pain and suffering of either a creator or a supporter can be eased by establishing a sound process.  For example, the daily interaction between a project manager and a developer can involve a lot of back-and-forth of questions and answers.  The project manager will want to know the details of how and when a certain bug was fixed, and the developer will ask “what was that list of fields they wanted added to that form?”  Lots of back and forth gets tiresome to both people, as they’re constantly interrupted in their work.  If they had a ticket tracking system to post questions and look up details, they wouldn’t have to interrupt each other for mundane questions.  The process involved here is requiring them to *use* the system, and to use it well.  In the end, it’s to both their benefit.

And the key word there is “both.”

After months of screwing around with it, I finally sat and read a bunch of people’s blogs and documentation on it, and got rails running on my box! Yay! This will help a bit with some of the prototyping I’m planning on doing. I’ll keep you posted.

I’m not entirely sure how long it has been, but apparently one of the interfaces on the machine I’ve got kicked it.   Unfortunately, that’s where I set the dns for my blog :(.  I switched ips, and things seem back the way they should be.

I’ve got a bit of work to do all at once, including getting Rails to run on this box.  There are some fun toys I’ve been building that I’d like to get served out of here.  If anyone can recommend good references on how to run Apache/lighttpd/rails/et al in tandem, I’d appreciate it!

Plus a new venture / direction for me.  More on that later!