But then as we begin to form our teams an interesting series of questions begin to come into play. What is the ideal ratio of technical people to non-technical people? Who - or what kind of person - should lead the group? Are non-programmers expected to touch code? Is it possible to divide teams into designers vs programmers (interesting if we consider that web programming isn't exactly MVC). And the big one: which of the two is more beneficial? To find people you can get along with, or to find people with good technical ability?
These questions (and how we approach them) are probably what our seniors meant when they talked about CS3216's emphasis on the 'soft skills set' of software development. I also suppose that what we learn from trying to get our teams to work together are lessons that we'll carry with us for the rest of our lives, out to the working world, even, especially so if we're required to work in small teams.
Are there answers? Well the good news is that we're not the only ones who've had to answer such difficult questions. In fact, a large portion of these answers are available online, on blogs by people who've taken the time to document the process of running small, web-based startups. Here are some of the ideas that I'm interested in testing:
Who Gets To Touch Code?
One of the first things we did when we formed our team was to figure out who would do what and why.
(Okay, Adhi's told me to cross this out, since it's not exactly correct. We're not sure how we're approaching the code, and we're not sure how the jobs are going to hold when the deadline approaches. Will tell you how it goes when we've finally started programming.)
A 37signals Take
37signals is a Chicago based startup that's been building webapps for the past 5 years. In their book, Getting Real, they talk about using teams of three for version 1.0 of any new webapp.
For the first version of your app, start with only three people. That's the magic number that will give you enough manpower yet allow you to stay streamlined and agile. Start with a developer, a designer, and a sweeper (someone who can roam between both worlds).
So that's another idea. Get a programmer, a designer, and a person who's sort of a jack of both trades. Perhaps more realistically, get two programmers, because it's likely that the programmers we have in CS3216 may still need to pick up the necessary technologies in order to code the app. Adhi is one, Kah Hong is another; I'm working as sweeper. Let's see how this experiment works out.
The Support Layer
The idea of a Developer Abstraction Layer comes from Joel Spolsky. He argues that software companies should be built around programmers, and everyone else working to make sure that the programmers are able to do their job.
Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.
We're working with Andy for the first Facebook app, and it's likely that the two of us would be the developer abstraction layer for the two programmers on the team. I am willing to do whatever it takes to make things easier for the programmers, even if that means wading into code and learning how to draw for the UI.
What I've Learned About Forming Teams
I've learned that it's not about me. I originally came to 3216 with the idea that we would all need to find the best people to work with/for ourselves, that it'll be an arms race to see who would be able to find the best talents. But the fact of the matter is that this isn't productive, and while it may make sense when you're hiring from a pool of willing developers, what we're really fishing in is a pool of equals, and so it would make less sense to hold interviews via email, and the like.
So instead of approaching people and asking them what they could do for me; I began approaching people and asking myself what I could do for them. What skills I had that could complement their abilities; what holes they had they I could help plug up. In simpler terms: I learned that the best way to form a good group was to approach the problem, asking: "how can I make their awesome abilities even more awesome?"
Things became a lot easier after I started thinking about it like that.
A Conclusion
I'm putting some of the above software engineering practices to the test, and I intend to document how it all turns out. There are a few other things, of course, such as how and what we're going to build - and what that is we can only tell, with time. I'm tired now. Off to bed.
Good night.
9 comments:
hi cedric,
it was great meeting you and stuff, i can feel the energy emitting from you =)
so this thing about forming a team, just my views on it.
i think that we should look at recruitment instead of hiring. recruitment means that you have to convince the guy to get out of his comfort zone, to join you. there must be a strong reason for that to happen. of course, you are one of the leaders that i see in this class, and you will have no problem with this.
hiring on the other hand, means you are getting the people who cannot find a group to join you.
of course a great leader can get anyone to work well in a team.
yup, just a couple of thoughts that came to my mind, and hope to see you around soon.
recruitment means that you have to convince the guy to get out of his comfort zone, to join you.
Alternatively - you get the guy to be comfortable enough to join you. ;-) I dunno. I find that it's easier to join up as a team when you're friends first. Or even a little familiar with each other.
I'm actually looking forward to working with people I don't know, however. I think it'll be a great adventure.
From what I can see, almost all of us are NON-DESIGNERS.
And the whole idea of this course is to explore and experiment with your limits. It would be good if you already know how to program, but you're NOT restricted to doing only programming.
Think about it, the same people designated to do design will be as new to their design software as you are.
Anyway my point is, I think any 4 (motivated)people in our particular class can and will come up with an impressive project, regardless of previous skill sets(of course, given at least 1 person who knows how to program). So there's isnt a real need to find a 'golden' combination or always reserve a slot for a 'designer'
From what I can see, almost all of us are NON-DESIGNERS.
You are mistaken. I am a designer. I don't advertise it as much because I do other things, but I can do pretty much anything you want me to do in CSS/HTML. So is Kah Hong, although he doesn't focus on it as much. Perhaps a better explanation of our team makeup is that I'm the designer, and Kah Hong is the sweeper, except that he's also the one writing the spec, and I'm also doing some management. But then again, such overlaps are to be expected.
But you're right, of course. Anybody can learn. Necessity is the mother of all inventions; and teamwork is still, I believe, the most important element in any team. I was merely discussing a few software engineering practices that has been proven to work in the real world, and that which I thought would be interesting to test here.
Hi Cedric,
Some thoughts on your articles.
http://administration.uco.edu/documents/exe_lbsFiveDysfunctionsOfATeam.pdf
http://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team
http://www.kvaes.be/blog/wp-content/uploads/2008/05/level5.gif
Might help =)
Ryan
http://blog.sina.com.cn/ryanteocc
Thanks for the links, Ryan. I think I've had some experience with almost all 5 archetypes before coming to NUS. It's remarkably ... scary to look at all the ways to fail.
One of the first things we did when we formed our team was to figure out who would do what and why. Adhiraj and I sat down, and we quickly came to an agreement that I would not be allowed to touch code. Brook's law says that "adding manpower to a late software project makes it later"
This is from Mythical Man-Month right?
Dun anyhow whack leh. What it says is that if your project is already in bad shape, you shouldn't be throwing more manpower at it thinking that'll fix the problem. However, you haven't even started on your assignment/projects!
This principle does not meant that the slower programmers just give up and do nothing!
When you have a job and you assemble a team, you figure out what needs to be done, who can do what and distribute the work out in an optimal way.
Some elite programmers think they are continents and refuse to let others touch their code. Happened before - but I don't think it's a good thing.
Yes prof, it's from the mythical man month.
I realize that the principle applies to software projects that are already late, but fact of the matter is of the three technical people - Adhiraj and I have to pick PHP up as a new language. Since PHP is based on C (or at least similar to it), Adhi is more likely to be able to learn the syntax faster than I am. Therefore I pass my books to him (the rest of the PHP books from the NUS library are borrowed, I wonder by whom.)
I'm focusing on picking up Javascript and other UI languages. No need to slow them down by writing sloppy code.
That, at least, is the idea, but I won't be surprised if I've to help debug when the deadline comes around.
I think there's been a communication gap. We did NOT decide that Cedric is not allowed to touch the code (we did not really decide anything as a matter of fact, I've just begun learning PHP!), so the previous few comments are really misleading. Anyhow, we've talked and I think the issue is resolved.
Post a Comment