vanderwal.net

Building a development team like an NFL draft

Build a development team like a NFL draft is a very good approach. This is a common approach and has work well for me in the past. The approach mentioned is along the lines of the build your initial development team with "athletes" and then add position players and specialists. This is just the people, it takes analysis, planning, and structure to get it out the door and get it right.

Speaking up on UI

Getting the UI right is tough and our be silent on UI issues is not helpful. We spend a lot of time working hard ot better understand the issues and solutions. Meg does a great job explaining this. This is a must read for developers, clients, and managers.

Software schedules with Excel

Joel shares his painless software schedules with Excel. Even if you do not use Excel the article has some great points.

UCD for different project types pt. 2

Now we have UCD for different project types, part 2.

UCD for different project types

IBM presents UCD for different project types. (I missed this when it first came online. I must be slipping of focussed elsewhere).

IBM Speed Team

Fast Company examines IBM's Speed Team, which has been working on developing speedy development environments. They cut back on processes that ensure proper development, but it seems like the the IBM developers have experienced developers, which make streamlining the development process much easier.

What Does Usability Mean: Looking Beyond ëEase of Useí from the fine folks at Cognetics. This solid overview focuses on the Five E's: Efficient, effective, engaging, error tolerant, and easy to learn. The toughest hurdle from my view is error tolerant, which is an often overlooked element in application and Web development. Planning early and knowing the user will help incorporate error tolerance into the development plans. One of the toughest areas to accommodate error tolerance is during feature creep as features grow and interact with various elements the probability for errors that do not have corrective paths accounted for rises greatly.

Joel explains the software development paradox when the technical folks and non-technical folks meet. I am very fortunate that I do not go through this at the moment, as I work for a client that understands the development process. I can not say that about every place I have been, but the developing a prototype in a few weeks that has rough functionality in it is light years from an actual product. The most important part of that next step is getting real data and getting a good understanding of the data and information you are working with as well as knowing what is to be done with said information. This being said is why many of us like using wireframes for interface development and not live GUIs (there are other reasons to use wireframes, but I will address that on another day, possibly real soon).

The Dev Shed offers a scenario many of us gone through in their Time is Money article. It walks through a tough scenario of delivering an intricate project with few requirements. In all it is a nice over view of developing a web based application using PHP and MySQL.

UIWeb posts a wonderful article on designers playing the politics game, which also provides excellent project strategies and skills for working with the client.