 |
|
|
|
About us
Currently, the only full-time Scissor employee is William Pietri, but a variety of freelancers join us as their skills, talents, and labor are needed. Want more details? Just ask! At Scissor, we believe that technology should help people get things done. This seems obvious, but a lot of software gets built for other reasons: because it sounds cool; because the programmers like the technology; because somebody has a vision. Not that we’re opposed to vision, but we like to treat it like a compass: we use it to figure out which direction to head, but we don’t follow it off a cliff. We put equal weight on all three aspects: the technology, the people, and the tasks they’re trying to accomplish. In the early days of computing, people took well-understood business processes (e.g., accounting, inventory, billing) and automated them; it was easy enough to take a close look at what an army of clerks were doing and then design software to do the same. Then, following the now-classic waterfall project life cycle, one would build and deploy the software without changing the design. These days, that’s not enough. Most software today does things that are so new or different from existing processes that the waterfall method doesn’t work. Imagine what would have happened if Yahoo's founders had tried to design its final form from scratch. That’s why we favor a style of design known as iterative design. Instead of guessing what you want and inflicting it on you, we go through a series of designs that zeros in on what actually fits your needs. Going hand in hand with iterative design is evolutionary delivery. Twenty years ago, the norm was for projects to take years to deliver useful software; now, that’s unthinkable. In evolutionary delivery, we schedule many short revision cycles; as often as every couple of weeks, you get a new version to use, test, and critique. And at the beginning of every cycle, you have the opportunity to set your priorities for the next version. This lets you start using the high-priority features right away, and makes sure that your software meets your needs. As an added bonus, you are never left wondering, "What are those guys doing?" When you see concrete results on a regular basis, there’s no mystery. Many developers are willing to give you estimates and commit to deadlines before they’ve heard all the details. Many developers are also famous for missing deadlines. At Scissor, we’re honest enough to tell you, "We don’t know how long that will take. But we’ll work with you to figure it out." This doesn’t sound as sexy as promising you the moon by Monday, but it beats missed deadlines by a mile. As part of an evolutionary delivery process, we are very comfortable with design-to-schedule projects. If you absolutely need something in six months, we’ll start delivering early versions months before that. Then we’ll keep adding features and delivering new versions until we run out of time; that way you are guaranteed to have a working version when the deadline hits. At Scissor, we are strong believers in getting real people to try out our products to make sure that they are easy to learn, understand, and use. We think that there are already enough VCRs blinking 12:00 in the world. For more information on why and how we like to do user testing, we recommend taking a look at useit.com, the web site of Jakob Nielsen, and especially his articles Why You Only Need to Test With 5 Users, the End of Web Design, and Are Users Stupid? (In case you were wondering, we think the answer to the last question is "no": technology should be made to fit people, not the other way around. Something that is hard to use is the sign of a bad design, not a bad user.) Extreme Programming (XP) As a rule of thumb, we treat things considered "the latest trend" with caution; most quickly become yesterday's fad. It is thus with some relief that we discovered that Extreme Programming has nothing to do with the caffeine-fueled coding rampages that its name suggests. On the contrary, it takes many time-tested techniques and bundles them into a lightweight but highly disciplined development methodology that minimizes risk while maximizing flexibility and customer control. For more information, see the books Extreme Programming Explained and Extreme Programming Installed. It's not suitable for every project, but when conditions are right we prefer it. Ask us if your project is a good match! |
|
| copyright 1996-2008 |