http://tc.eserver.org/publisher/Sprezzatura_Systems A listing of works published by Sprezzatura Systems in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/Sprezzatura_Systems http://tc.eserver.org/35621.html http://tc.eserver.org/35621.html Some of my designs never make it to market due to lack of funding prior to release and the company slips quietly away or gets bought and I lose contact. Other times by the time the software is released, the person who hired me has left the company and moved onto other pastures. So it's always a treat when someone calls me back to say "Would you like to come in and see the software? We're nearly done." http://tc.eserver.org/35622.html http://tc.eserver.org/35622.html It struck me while reading this that cultural blind spots are not limited to people who speak a different language, come from a different country, or have a different religious background—we have huge cultural blind spots between the various job functions in a single company! http://tc.eserver.org/35623.html http://tc.eserver.org/35623.html One of the online lists I read frequently has been debating the proper metaphor for the software development environment. The building trade has been used quite often in the past. In fact, we use the term "architect" quite frequently, although ten software engineers will probably give you ten different definitions of what an architect actually should do. I think there is no single metaphor for software development roles because there is not a single software development environment. http://tc.eserver.org/27574.html http://tc.eserver.org/27574.html This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design. http://tc.eserver.org/27572.html http://tc.eserver.org/27572.html What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code! http://tc.eserver.org/27575.html http://tc.eserver.org/27575.html Your requirements document needs to focus on the user’s goals. They should not be marketing’s list of features 'we’ve got to have' because the competition has these features. They should not be a list of things the programmers think ought to be included 'because we can add those things for very little cost.' Feature bloat does not benefit the user. http://tc.eserver.org/27576.html http://tc.eserver.org/27576.html Handheld devices and small appliances pose a unique challenge to the interface designer. The blur between user interface and functionality (interface vs. interaction) is even more pronounced in these environments. The interface of any small device is extremely important; yet, more than ever, the necessity to build in exactly (and only) what is required by the user is extremely important! http://tc.eserver.org/27573.html http://tc.eserver.org/27573.html Software is sometimes poorly designed to begin with and the interface should be scrapped and rebuilt from scratch. But more often than not, I see software that started with a decent design and has since had features added onto it with each release, squeezed into the existing design rather than being designed in. People aren't in a design mindset but an 'enhancement' mindset somehow. http://tc.eserver.org/27577.html http://tc.eserver.org/27577.html Your requirements will assist you in delivering a software solution that meets your users' needs. You can find all sorts of templates and formal processes for requirements of various kinds, and while they are useful, the biggest problem I've found is that most people confuse defining the need with proposing a solution. As soon as a requirements document contains any part of 'how we're solving this', you've crossed the line into presupposing that you already know what the problem is and can stop listening. http://tc.eserver.org/27578.html http://tc.eserver.org/27578.html In any software development methodology, there's a secret ingredient that doesn't get enough press. It doesn't matter whether you follow Cooper, Beck, McConnell, or anyone else on the long list of notables. http://tc.eserver.org/27579.html http://tc.eserver.org/27579.html Smart and energetic people believe 'Never put off till tomorrow what you can do today.' Smart and lazy people say 'Never do today what you can put off till tomorrow!' This is, to me, one of the most useful tenets from the eXtreme Programming movement. http://tc.eserver.org/27580.html http://tc.eserver.org/27580.html As I write the 'how to' documentation based upon the in-process design, the weaknesses of my original design become apparent and I go back and forth from writing text to designing the software until it all flows. http://tc.eserver.org/27581.html http://tc.eserver.org/27581.html Let's say you've got a clear set of requirements; the users have been defined, the features are associated with user tasks, marketing has done a competitive analysis and everything is good to go. Now what?