The most important thing in software development is motivation. Motivation is local — if you aren't motivated by what you are working on right now, then chances are it won't be as good as it should be. In fact, it's probably going to suck.
Long, drawn out release cycles are motivation killers. They insert too much time between celebrations. On the other hand, quick wins that you can celebrate are great motivators. If you let lengthy release cycles quash quick wins, you kill the motivation. And that can kill your product.
So, if you're in the middle of a months-long release cycle, dedicate a day a week (or every two weeks) for some small victories. Ask yourself "What can we do and release in 4 hours?" And then do it. It could be...
A new simple feature
A small enhancement to an existing feature
Rewriting some help text to reduce the support burden
Removing some form fields that you really don't need
When you find those 4-hour quick wins, you'll find celebration. That builds morale, increases motivation, and reaffirms that the team is headed in the right direction.
Source: svn
Tuesday, 20 December 2011
There's Nothing Functional about a Functional Spec
Don't write a functional specifications document
These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:
Functional specs are fantasies
They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.
Functional specs are about appeasement
They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.
Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.
Functional specs force you to make the most important decisions when you have the least information
You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.
Functional specs lead to feature overload
There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.
Functional specs don't let you evolve, change,and reassess
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.
Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.
Source: svn
These blueprint docs usually wind up having almost nothing to do with the finished product. Here's why:
Functional specs are fantasies
They don't reflect reality. An app is not real until builders are building it, designers are designing it, and people are using it. Functional specs are just words on paper.
Functional specs are about appeasement
They're about making everyone feel involved and happy which, while warm and fuzzy, isn't all that helpful. They're never about making tough choices and exposing costs, things that need to happen to build a great app.
Functional specs only lead to an illusion of agreement
A bunch of people agreeing on paragraphs of text isn't a true agreement. Everyone may be reading the same thing but they're thinking something different. This inevitably comes out later on: "Wait, that's not what I had in mind." "Huh? That's not how we described it." "Yes it was and we all agreed on it — you even signed off on it." You know the drill.
Functional specs force you to make the most important decisions when you have the least information
You know the least about something when you begin to build it. The more you build it, the more you use it, the more you know it. That's when you should be making decisions — when you have more information, not less.
Functional specs lead to feature overload
There's no pushback during spec phase. There's no cost to writing something down and adding another bullet point. You can please someone who's a pain by adding their pet feature. And then you wind up designing to those bullet points, not to humans. And that's how you wind up with an overloaded site that's got 30 tabs across the top of the screen.
Functional specs don't let you evolve, change,and reassess
A feature is signed off and agreed on. Even if you realize during development that it's a bad idea, you're stuck with it. Specs don't deal with the reality that once you start building something, everything changes.
So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real. Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, then it's too complex. This process shouldn't take more than one day.
Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into html. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.
Confusion disappears when everyone starts using the same screens. Build an interface everyone can start looking at, using, clicking through, and "feeling" before you start worrying about back-end code. Get yourself in front of the customer experience as much as possible.
Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you'll keep change cheap and stay flexible.
Source: svn
Monday, 19 December 2011
Hire Less and Hire Later
There's no need to get big early — or later. Even if you have access to 100 of the very best people, it's still a bad idea to try and hire them all at once. There's no way that you can immediately assimilate that many people into a coherent culture. You'll have training headaches, personality clashes, communication lapses, people going in different directions, and more.
So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?
Whenever Jack Welch, former CEO of GE, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.
If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.
Source: svn
So don't hire. Really. Don't hire people. Look for another way. Is the work that's burdening you really necessary? What if you just don't do it? Can you solve the problem with a slice of software or a change of practice instead?
Whenever Jack Welch, former CEO of GE, used to fire someone, he didn't immediately hire a replacement. He wanted to see how long he could get along without that person and that position. We're certainly not advocating firing people to test this theory, but we do think Jack is on to something: You don't need as many people as you think.
If there's no other way, then consider a hire. But you should know exactly who to get, how to introduce them to the work, and the exact pain you expect them to relieve.
Source: svn
Design the interface before you start programming
Too many apps start with a program-first mentality. That's a bad idea. Programming is the heaviest component of building an app, meaning it's the most expensive and hardest to change. Instead, start by designing first.
Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your product. What people see is what you're selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.
Source: svn
Design is relatively light. A paper sketch is cheap and easy to change. html designs are still relatively simple to modify (or throw out). That's not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs.
Another reason to design first is that the interface is your product. What people see is what you're selling. If you just slap an interface on at the end, the gaps will show.
We start with the interface so we can see how the app looks and feels from the beginning. It's constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are questions you can only truly answer when you're dealing with real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later.
Source: svn
Wordsmith
If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Other fact: clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.
Source: svn
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Other fact: clear writing leads to clear thinking. You don't know what you know until you try to express it. Good writing is partly a matter of character. Instead of doing what's easy for you, do what's easy for your reader.
Source: svn
Start With No
"We Don't Want a Thousand Features"
Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?".
Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.
Source.
Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. My favorite line of the day was when people kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?".
Finally Jobs said, "Wait wait — put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features.
Source.
Ignore Details Early On
We're crazy about details.
The space between objects
The perfect type leading
The perfect color
The perfect words
Four lines of code instead of seven
90% vs 89%
760px vs 750px
$39/month vs. $49/month
Success and satisfaction are in the details.
However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn't real progress? This happens when you focus on details too early in the process. There's plenty of time to be a perfectionist. Just do it later.
Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.
Source: svn
The space between objects
The perfect type leading
The perfect color
The perfect words
Four lines of code instead of seven
90% vs 89%
760px vs 750px
$39/month vs. $49/month
Success and satisfaction are in the details.
However, success isn't the only thing you'll find in the details. You'll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn't real progress? This happens when you focus on details too early in the process. There's plenty of time to be a perfectionist. Just do it later.
Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you're building. You'll see what needs more attention. You'll feel what's missing. You'll know which potholes to pave over because you'll keep hitting them. That's when you need to pay attention, not sooner.
Source: svn
Subscribe to:
Posts (Atom)