Posts Tagged team

On Agility

May 30

Posted by Jack Lawson in General, Team Dynamics | No Comments

: Image via Wikipedia

The most important quality of any IT company- web-based or otherwise- is the ability to quickly change, to turn on a dime. The openness and ability to foster innovation is absolutely critical, even expanding past IT companies; without change, you fall behind. And when you fall behind, it is only a matter of time before the inevitable collapse.

I read an interesting article in Wired yesterday about car companies. It suggested they become more like the computer industry, setting standards for components and allowing hundreds of parts manufacturers develop these sort of plug-in devices. These manufacturers would be smaller and agile, developing new, efficient parts, which not only helps the company sell more, but also gives consumers the chance to purchase better products. The big car companies would be like Dell, offering a sort of base upon which to customize and put together these parts.

The key here is that in a vertical company, where all processes are overseen by a massive beauracracy, is unable to change, while the hundreds of small parts manufacturers, overseen by a standards commitee, are each able to introduce breakthroughs in their respective areas. It is the same way with any IT company; one who is overseen by a large beauracracy is never going to stay with modern times. They are the ones still using IE6, to support their apps and unwillingness to change, while small 5-man companies are able to revolutionize the web with things like Youtube, Flickr, Twitter. When was the last time a large company built an app like that?

A lot of this requires upfront planning. The huge company is reluctant to change after investing millions in a system that is rigid; a properly planned system is one that is flexible; one should never think that you can build the perfect long-lasting solution. You can get close, but five years down the road, something will inevatably be superior and your app must be rewritten. Modularize your development and make this possible, because it is a matter of when, not if.

It is imperative that innovation is prized, that a company does demand absolute, 100% control, because when this happens, a company loses its character and becomes dead in the water.

Tags: management, team

On Management

Mar 11

Posted by Jack in General | No Comments

There are two kinds of managers, the way I look at things: managers who stifle creativity, and those who endorse it.

Looking
back through my life, I find that I have had huge problems with the
first kind, and I’ve had a great time with the second. It usually
seemed to rear it’s head during my math classes. It started in
elementary class, and continued to fight and struggle every year except
one- my senior year. I remember back in Freshman year, during geometry
we were doing math problems that took half a page to complete. “Aha,” I
noticed, “I can just use the pythagorean theorem and cut it down to
about three lines.” Of course, this didn’t fly with my teacher, who
held a strong affinity towards doing things the way the book did them.
Now, I’ll agree, there are arguments towards doing it by the book
(“teaches you how to do it that way” is the general response), but I’m
a huge proponent of if it works better another way, then do it. As I
argued then- I know how to do it, and I know how to do it faster,
better, and with less points of failure.

This all continued, and
came to a huge head during Trig, Junior year. A friend and I wrote
programs every day, instead of taking the notes, that did the homework
for us. We even accomodated to our teacher’s archaic views and
developed the programs so that they showed the work; she, of course,
hated it, but it worked quite well. Then, finally, my senior year I had
Calculus AP; the first math that really challenged me, but at the same
time, the first math class I enjoyed for 5 years. It was only myself
and one other person in the class- we had started with 11, and the
other 9 dropped out- along with our teacher.

The reason I liked
the class so much was because she didn’t require work, and she didn’t
require that you simplify answers, and she didn’t care about the final
format, as long as it was right. It helped to show your work, so that
you could find errors, but you didn’t have to. You had the freedom to
do the work however you wanted to, you could find shortcuts and ways
around that worked better and made sense.

I find myself
harboring the same feelings in the workplace. I was an intern at a
company for about 8 months, where the projects came three-a-day, and it
was 85% copy and paste from other code. The other 15% was debugging. It
was all classic ASP (which suprised me more and more as time went by..
it was 2007, after all), and it was badly written. Something needed to
be done; however, there was no room for innovation, no room for, say, a
nice .net framework, not anything except heads-down coding. I was,
effectively, a code monkey.

My current place, however, is an
exception. In the same way as I found myself in a wonderful place after
moving from Trig to Calc, I find myself with creative freedom; if I
have an idea that will speed up processes, or that will help out in
some other way, and I’ve got down time- I can work on something.
Recently, I made a program that took some basic copy-paste work we did
from 20 minutes down to about 2- something I was a bit apprehensive to
show off, but, finally did to great reception. It gave me new hope that
there was somewhere that I could fit in and try new things out. We
later attempted integrating a wiki, which also worked wonders; the
whole team could now communicate and store data, instead of throwing
word docs around in VSS.

Now, I’m not advocating running off and
doing projects whenever you feel like it, and wasting company time to
try some thought out. However, I am advocating that if there’s a
genuinely good idea, and you’re not hammered down with work- creative
freedom is the best kind. It helps thoughts flow, and it sometimes pans
out to be a great development that can help out, and even occasionally
revolutionize the whole development team.

Tags: management, team

The Perfect Team

Feb 5

Posted by Jack in Development, General, Web Design | No Comments

A Perfect World?
In a perfect world, designers know how to develop, and developers know how to design. However, this is often not the case, and as has been brought to my attention recently, it can seriously bog down and lessen the quality of any user interface. There is a layer of overlap between the design and development teams of any project that needs to exist to facilitate perfect cooperation and a flawless user experience.

Problem Number One: Designers who don’t understand code
There are two main strains of this problem that I have seen take place. The first is that the designer holds himself back from creating a perfect design, unsure of whether or not things are possible. “Is it feasible to have X feature?”, he asks himself, and ultimately leaves it out of the design. Although the final product looks good, it could look better. The second problem that I have noticed is when designers go over the top with their designs, and implement design features that go against the code base, adding awkward features that look great but don’t necessarily scale. What works in flash, for example, does not always work so well in plain old HTML. This is where the code knowledge comes in.

A designer with at least a little development experience should have a general idea of what he can do, and will feel more comfortable speaking with developers with the “How about this?” sort of question. The developer and designer will be able to speak the same language, and can come up with a farsuperior solution.

Problem Number Two: Developers who don’t understand design
This is, in my opinion, far worse than the above problem. I have seen countless examples of perfect, flawless, completely unusable applications. Many developers see things very differently than designers: they design to display the data they output, and organize layouts according to the back-end. I frequently have drawn-out debates with a friend of mine, with whom I have been working on an online game. A recent argument went something like this:

“Matt: The defend and the attack forms are the exact same.
Me: Yes, but, they serve very different purposes. Defend is set-and-forget, attack is something that changes every round.
Matt: But the forms are the exact same, so they should go in the same place.
Me: No, the attack form should go where the attacks happen, the defend should go with the long-term options storage, since you only set it once, like the other options…”

And, so on, for a few hours. I’ll spare you the details. I’m sure you can tell who’s who: Matt is a developer, and only a developer. He is right; they are the same fields, the same select boxes, the same buttons. However, from a user’s perspective, they are radically different, because one is reset every few seconds during a fight. Matt is a brilliant developer; but, an intermediary needs to fight for the user, because the developer cannot always see from their standpoint when they’re used to thinking about pure functionality.

Go to the Library
What this all comes down to, is that each side should take a moment, and sit down and learn the other’s trade. Developers should see why designers do what they do, and designers should feel open to taking suggestions and discussing ideas with developers. It is when this happens that well-designed, attractive, usable applications can be developed.