Tuesday, February 16, 2010

Information Architecture (IA) That Sucks Less

If you have ever went to a site that was hard to use its probably because someone left it up to the developers to make the site "look OK". Often as a web developer on a small team, we don't have the resources of large enterprises. Tasks like usability and design often fall to the developer writing the web pages.

Since I've found myself in this position more than a few times, I decided I could learn a little about these fields that might help me suck less at it. I found a book called . Its a great introduction to Information Architecture (IA),this is a fairly new discipline and there are many views on what an IA is and what it should they be. Are they the designer that focuses on the look and feel or in my case the developer that makes is all work together? It could be creating the content or focusing on usability. In truth its a little of all of this, that's why its so hard. Maybe some of the larger projects would need a formal position, but I think we can go a long way by learning a little ourselves and making the interface of our sites suck less.

Theory of Constraints and The Efficient Programmer

The Theory of Constraints is a management theory that comes from the book The Goal. Basically it says in a process there are a few constraints that limit how fast the whole pipeline works. An example in software development would be waiting on the database team to design the tables or the waiting for BAs to write the requirements. If they are the slowest point then it doesn't matter how fast we code. The book also talks about optimizing points in the process may or may not help the entire process.

Why is this? Imagine a factory floor that produces widgets. The process has to go through 10 machines. One of the machines is 1/2 as slow as the rest. Its obvious that this will result in everything piling up in front of the machine. However, what if some engineers tweaked another machine so it was 2 times as fast. First a backup would occur in front of the machine that comes after the machine that runs faster and the other thing is that the process is not any faster. Since we still have one machine running at 1/2 the speed it doesn't speed up the overall process. The most efficient use of our resources would be to optimize the slow machine.

How does this relate to being an efficient programmer. I've seen efficient programmers get their work done and always try to get more work. Their utilization looks good, everyone comments on how fast they go through the code. However, do they ask questions of the lead who is already swamped. Do they bother other resources that our busy with fixing priority defects, do they do anything to improve the process. In other words are they optimizing their work at the expense of the overall process. In the goal it suggests that it may be better to idle a resource rather than have it pile up backlogs. I'm not suggesting that the person sits and twiddles their thumbs. I'm saying they should be aware of what time and resources they are pulling to get their task done and is pulling those resources away the best for the overall project. Could they work on unit tests or conducting a spike on a new technology, updating documentation or somehow improving the throughput of the entire process instead of a laser beam focus on getting their code done. Could they look at who has the most work and pair program or take some workload off of them. I feel this would be a better use of their time.