Whatever you are trying to accomplish as a team, you need some things.

You need to know what you intend to build. Depending on whether you're trying to create a new market or compete in a large field, you might have a clear picture of the end result, or a lot of ideas you need to try out. Where you fall on that spectrum should tell you how far you're allowed to plan in advance. Rarely do you need to change what you're building on a timeline as short as a week, but of course that can happen, too. But given that planning and meetings require time, and rework also requires time, you need to find a balance that works for your team size and the above allowance of planning based on volatility of your goals.

Someone has to be able to make decisions. Often those decisions are high-level - what is the market value of the thing you are building, and how many resources are you willing to allocate. We know in software that estimation is hard and we will get it wrong, so that's always going to be a thorn in the side of the decision-makers, and some of them will always try to offload that responsibility back on us anyway. Still, at some point it is reasonable to relay how well things are going back up the chain.

You need to be able to share plans, decisions, constraints and a swath of other information among team members. Some of it will be for builders. Some will be for decision-makers. Team structure will probably dictate how important leadership and decision-making is compared to maker details. And that structure will hopefully flow from the kind of thing you're building, whether it's just an idea, or something that has to be done a particular way against a particular cost profile to ensure it's worth doing at all.

There's plenty of room in all of this for ambiguity, for conflict, for human errors, for ego. For prioritizing the wrong thing (whether that's the thing to work on, or the thing to measure, or how much of a stink you make about mistakes.)

Given all of the above, what I don't like about Agile is the tendency to put off figuring out how you're going to build things until the last minute, and in the middle of figuring those things out, you change what you're going to build. If you're building out ideas and moving fast and breaking things, then that pain I just described is something you have to accept as one of the costs of being a pioneer. In so many cases I've seen, you're not being a pioneer, so if you spend a bit more time on planning, you'll figure out what to build and how to build it, and then each member of the team will buckle down and focus on the details required to do to the building.

Focus, and less volatility. That's what I want out of the process in play for accomplishing something. I think the decision-makers mostly don't want to be caught out making a bad decision, such as spending resources to build something only to find that the value isn't there - either because of the market, or the unknowns in resource cost.

I'm working on a web design. I've done a few before. Technically this site and a handful of others were "designed" by me, but the art of web design is something I've never learned, and it's still difficult for me to conceptualize aesthetically pleasing designs. I also have a lot to learn about Photoshop before I can bring concepts to life. And I'm pretty bad about finding a good set of colors that work well together. So the deck is stacked against me. But I have a book I'm borrowing from work which walks me through the process and ideas behind creating a web design. In some ways, I'm liking what I've come up with so far, but I also leaned on Carlos a lot for suggestions including one of the fonts, the color palette and some of the navigation design elements. I've taken a few days off from working on the design though, and want to get back to it, either tweaking what I've got, or starting over with what I've learned. I could just settle, but I'm trying hard to work towards achieving a professional looking design. That sort of "final 10%" is the hard part that I need to learn if I'm ever going to resume doing freelance regularly, even if a lot of the design work still ends up being done by someone else.

Once done with the design, I can start in on yet another new challenge, which is coding the visual presentation elements of a web site. This involves learning how to effectively use valid, semantically significant XHTML (markup to help bridge the gap between textual content and how a web browser will interpret it) and using CSS (style and layout commands that work with HTML to take the content from meaningful to beautiful) intelligently. I've learned some key points in using CSS lately, and hope I can apply it to this new project.

And then I can work on another technology I'm in the process of learning. That's .NET 2.0. It's a difficult decision for me to switch from using (older, sometimes considered obsolete) Classic ASP to this newer framework and language for building web sites with a database and application base, because I know ASP so well and can accomplish a lot in a short amount of time. Unfortunately, the work and the money will all be through .NET in the future (and even today), so I really need it to keep working in this field. And fortunately, you can do some things with .NET without purchasing third party components like you often did with ASP, particularly resize uploaded photos.

All the while, I'll be practicing my database architecture and user interface design skills and trying to take a best guess at what functionality and features will be useful for (and used by) the target audience, a picky group of individuals that are reading this blog post right now.

For some people, web browser choice is very important. So why is it that so many business entities think it is OK to take that choice away?

Recently, I tried to browse the Lowes.com web site using Firefox 2.0.0.6. After entering my zip code, every page I browsed to froze the browser for a short while. Firefox alerted me that a script was running endlessly, allowed me to stop the script, and then the process repeated. Each page threw up an infinite script twice.

So I contacted their customer service alerting them to the issue, hoping they would fix it, but it's been a while since I've been optimistic about customer service. My pessimism was right on the money. They replied that I may experience problems when using browsers other than Internet Explorer or Netscape. Oh and I should enable my browser to accept cookies.

The solution to poorly written JavaScript code is that I stop using my browser of choice (and a more popular one than Netscape at that). Cookies were already enabled and were irrelevant to the issue.

Wait a second... the solution to a company giving me a bad user experience is that I change? That is the most ridiculous thing ever, but it's not at all uncommon. Of course, we've been trying to steer away from that exact issue for a very long, because the days of "Best viewed in..." should be long over. I guess not everyone got the memo?

Successfully designing a user interface is quite a feat. One of the main difficulties is being able to measure success. Many users are quick to blame themselves for any issues they encounter. Rather than finding an issue with the poor design, they decide they just don't have the skills needed. Because of this, I feel that a successful design is one that pleasantly surprises users by working just how they expect it to. Before they know it, they feel like masters of this new application, and that is a great feeling. That's the kind of thing that will entice them to spread the news and get other people interested.

It has been a great couple of months during which I've kept very busy. I'm working on a non-public web application, and as the launch nears, I'm excited to see it in action. I think what was even more exciting was working on this as a team. I've done a lot of projects as an individual, but as the project sizes have grown, it's started to make more sense to include more developers. This also helps everyone develop their own place within the team.

It's not unusual for me to do system architecture and database administration, since it's just one of the many things a project needs to be completed. For this project, though, I got to focus on it, and put a new perspective into it. This time I had to think about how a programmer that isn't also the architect will be seeing the code. They'll need some way of knowing what they can do with existing functions and database interfaces to easily complete their tasks, without knowing the whole system behind it, how the data might be stored and accessed, how certain checks are in place. Thinking this way as the architect forced me develop some very flexible stored procedures and application-wide functions that were also relatively self explanatory in their usage. It seems to have worked, because the programmers picked up their tasks and took off running, getting us from here to there quickly and smoothly. And I found myself not only happier with the overall product, but really enjoying the team environment, perhaps more than I expected.

Of course, I still did serve as project manager, and as many new to management will find, it's so very hard to let go of the things you did before. I helped with programming just because of the size of the project, but I really had to watch myself to avoid micro managing the other programmers in how they accomplish their share of the workload. I'm sure I wasn't perfect, but I hope to improve upon this skill as I exercise it more, and help the programmers grow and learn. That way I can fill in for fewer roles, focusing on the areas that make the most sense within the team, and being the best I can at those.

Over the past year, I've been developing a lot of projects for a variety of reasons. Sometimes I have a simple problem to solve. Sometimes someone else has a request. Whatever the reason, there's also the need for practice and innovation. So I put together these projects, and I want to share them and discuss them. But until now, I didn't have this outlet. So I pushed up this tiny project on my list of priorities.

One of the first projects I started dabbling with this spring was a JavaScript driven calendar, taking full advantage of the document object model (DOM) and Ajax to display a fast, simple calendar. The main motivation for this was my outdated HTML tabled based calendar that uses ASP to access data, and SQL to store it. The big challenge was allowing for recurring events, but keeping the interface fast. With JavaScript, I found a way to do that, and along the way learned a lot and implemented my first Ajax application that doesn't break the back button or bookmarking capability in any major browser. I've still got a lot of work to complete on the calendar, as I'm still relying on HTML forms to add and update events.

Once I got my feet wet, I started seeking out projects for practice. One of these is a simple list application. You can use it for tasks, bookmarks or anything you want to keep a list of. This one is fully operational. Once you've loaded the page (which is very quick), you don't have to leave it to do anything. I took this opportunity to take my ASP based function for pulling URLs out of user entered content, and rebuilding it in JavaScript. I quickly found that regular expressions were a much better approach to accomplishing this task, so I brushed up on them and also pulled that methodology back into the ASP version.

With both of these applications, I found the need to pop up "windows" and I wanted to be able to drag them around. So I set it upon myself to make a reusable set of code for this purpose. This is when I came across object-oriented JavaScript using prototypes, which work much like classes. I made a class for dragging objects that is easy to add to other applications, and I used it in my other projects. I decided going forward that most applications would be better accomplished using the class approach.

Another nifty feature I put together which I think is more interesting to most people and used by many is a Google Suggest type of search interface. I put this together for my photo database, which I've tagged with keywords. With this new search interface, you can start to type keywords, and get a suggest list which shows how many photos match each possible keyword. You can use the keyboard or mouse to select one of the suggestions, or if there's only one suggestion left, you can hit enter. Then, without leaving the page, thumbnails of all the matching photos load, and you can click on them to load the full-sized image. This full-sized image also uses the object dragging class. You can enlarge more than one photo and drag them beside each other for comparisons.

The final project I'll mention has gone through a lot of changes, and still has a lot of work left as well as a lot of potential uses. I envisioned it being used to create web site wireframes or prototypes, but it has progressed through some stages. At first it was simply a drawing tool, where you could make different colored rectangles, either outlines or solid. Then I added the ability to add text, and at this point you can format the text using a basic WYSIWYG interface. I've found that the more I work on this project, the more ideas I have, so this is one project I want to slow down, so I can take a good look at where it could go and how I can get there, rather than continue to change the application blind to the desired end result.

With that, I'll wrap this up. I hope to use this to continue to provide an insight into internal and external projects that I work on, and as I add features to the blog, to get feedback about what interests you and what you think of the work I've done.