SitePoint had an article today relaying some thoughts about User Experience, the catalyst was an interview with Andy Budd. Basically he was talking about how web designers could learn a great deal by paying attention to how other industries manage user experience. It is an interesting read for sure, but what got my attention was the realization that I really don't know much about Design in general, and this isn't really a problem.
I have seen a few rails projects go by where there is this resistance to hire a designer to be a part of the team. And I think this is understandable when a dev team manager looks at the deliverables. The reality here is that, on the web these days, the bar is set pretty low and a developer with a decent eye and knowledge of CSS and HTML and Javascript can put something together that even looks good. So we think this was a good decision, a designer would just cost more and get in the way. This approach inherently risky to any project.
Most of the time developers and designers not only have different skill sets but they have trained their brains to look at problems differently. How many times have you seen a mock that has unintended features on it? That is a great thing and this is at the core of the issue. When you ask your developer to do design they are going to do it within the current constraints of the code base, and even worse they will do it within the constraint of their skill set. A designer will often not be inhibited by these things and you will get new or better ideas and the ideas will come from the desire to provide a positive User Experience.
Many times your developer won't be willing or even interested in providing PhotoShop mocks of the intended design. He will dive right in and start coding it up, this is because he is a developer, he is interested in development , and as such he will pay attention to the implementation details. This can cause a considerable loss of efficiency, simply because many of the design ideas will not actually be accepted as features in the product. I have seen this happen again and again. And what is even worse than the feature not being in the product, is that code design decisions would have been made to support the feature. This is particularly unappealing because the code debt will live on , even without the feature and will be a constant distraction to the developers maintaining and adding to the project.
I am sure there are many people out there that would be surprised the people don't believe that they need designers , since it is a standard in the industry, but there are a lot of new comers to the web space these days and they are only looking for the deliverable. They will happily allow their new application to look as if it emerged directly from the database and think that it is amazing.
We are lucky at TravelersTable, we have Doug Fales at the helm. He is a very strong developer and is intensely interested in usability and design. So we are getting rid of the tabular , straight from the data model, design and going with something much more appealing. Don't fool yourself, unless you have a guy like this you will not know what you are missing out on.
Wednesday, May 21, 2008
Wednesday, May 14, 2008
The shortest path takes too long to find
At first I named this blog Shortest Path, but I quickly realized that I am not oriented around finding the shortest path. The shortest path can often take too long to find, and often it isn't very fun getting there. I think there are lots of examples in modern software development philosophies that ring true to this idea.
Premature Optimization, why is this generally held as a bad idea? Because the art of software development is complex, and we just don't know where we are going to end up at the end of the day. A great deal, maybe even a majority, of features that are added to applications either never get used by customers or worse never even make it into the product. So until you know that performance is a problem in your code and until you know that people will use it, don't bother. It is likely to be a waste of time and attention. Choose the short path, finish the feature and move on.
Premature Feature Building, I think I touched on this above but I think this deserves its out shout out. More and more the successful software companies are building for people, and they include those people in the process of development. In Extreme Programming this is evident in the rule of having a customer as part of your development process. This is because more often than not your customer does not really even know what they want, and you as a developer or entrepreneur certainly don't know. So, instead of guessing, start small. Build out the minimal amount of features to get someone's attention. If you can't get their attention then iterate until you find a way to get their attention. Adding features is not a way to get someones attention, it may be a way to keep their attention for a while longer, but you won't get them to stay by giving them a long list of things that they could do with your software. Take the short path, you might end up building all the same features but do it from a place of informed strength.
Test Driven Development, this is the best example of the difference between finding the shortest path and taking the short path. The shortest path would dictate the you always achieve complete code coverage with your tests. Some people even advocate throwing complete garbage at your code, or mixing up the decision tree to see that everything breaks in the correct way. It is believed that if you do this you will greatly accelerate your teams development because they will have a safety net of tests to protect them from lengthy bug cycles near the end of a release. I do believe that the tenets here are true, but I don't do it. I don't do it because it take a lot of attention to build out these test suites and keep them current. I think that the real advantage of writing tests is that it allows you to focus your attention on the specific problem that you are working through. Once you have tamed the problem, move on, take the short path. If you spend a couple more days getting code coverage you will probably find that in a week the features have changed or that entire business unit has closed down.
Premature Optimization, why is this generally held as a bad idea? Because the art of software development is complex, and we just don't know where we are going to end up at the end of the day. A great deal, maybe even a majority, of features that are added to applications either never get used by customers or worse never even make it into the product. So until you know that performance is a problem in your code and until you know that people will use it, don't bother. It is likely to be a waste of time and attention. Choose the short path, finish the feature and move on.
Premature Feature Building, I think I touched on this above but I think this deserves its out shout out. More and more the successful software companies are building for people, and they include those people in the process of development. In Extreme Programming this is evident in the rule of having a customer as part of your development process. This is because more often than not your customer does not really even know what they want, and you as a developer or entrepreneur certainly don't know. So, instead of guessing, start small. Build out the minimal amount of features to get someone's attention. If you can't get their attention then iterate until you find a way to get their attention. Adding features is not a way to get someones attention, it may be a way to keep their attention for a while longer, but you won't get them to stay by giving them a long list of things that they could do with your software. Take the short path, you might end up building all the same features but do it from a place of informed strength.
Test Driven Development, this is the best example of the difference between finding the shortest path and taking the short path. The shortest path would dictate the you always achieve complete code coverage with your tests. Some people even advocate throwing complete garbage at your code, or mixing up the decision tree to see that everything breaks in the correct way. It is believed that if you do this you will greatly accelerate your teams development because they will have a safety net of tests to protect them from lengthy bug cycles near the end of a release. I do believe that the tenets here are true, but I don't do it. I don't do it because it take a lot of attention to build out these test suites and keep them current. I think that the real advantage of writing tests is that it allows you to focus your attention on the specific problem that you are working through. Once you have tamed the problem, move on, take the short path. If you spend a couple more days getting code coverage you will probably find that in a week the features have changed or that entire business unit has closed down.
Subscribe to:
Posts (Atom)
