I love refactoring code. Moreover, I think refactoring can also be used when looking at software demos.
I love looking at a piece of code that works (for the most part) but just doesn't feel right and taking it apart and putting it back together so that it makes more sense, not just for me but for the next person who comes along.
I find it funny that refactoring and unit testing come from the same core concepts (Agile) because if done correctly, code that was properly unit tested SHOULD result in code that is pretty well-written and refactor-proof. (I'm no expert on the philosophies behind this so please comment and rip this post to shreds)
So refactoring really comes into places where you've got unwieldy code (or worse, legacy code) that no one really can wrap their head around. By the time you've finished refactoring, you possibly COULD have some ways of unit testing it (if you were able to separate each logical piece out).
So how does this apply to demos?
Depending on who is giving the demonstration, a demo will consist of the following:
a) overview of features
b) description of benefits
c) demonstration of functionality
d) explanation of functionality
e) review of benefits / explanation of results
and possibly
f) showing of additional features
The actual content differs by person:
If a sales person gives a demo, it likely goes a->b->e.
A sales engineer: a->c->f->b (possibly e)
A developer: a->c->f->d (and sometimes you don't even need a)
A trainer: a->d->c
A trained user: c
If you want to really look at a valuable demonstration, why not refactor each piece of the demonstration asking the following questions (in this order):
1. What benefit are you trying to show?
2. What feature showcases this benefit the best? *
3. What is the bare minimum I can show to highlight this feature?
4. Is the result obvious?
* If more than one feature gives this benefit "best", then you may want to rethink the design.
How does this relate to refactoring code? Re-ask the questions, thinking about code:
1. What is this block of code supposed to do?
2. How could I rename this to make it easier for others to understand?
3. Have I made this as simple a call as possible for this function to run?
4. Is the result obvious to the calling program?
Development and sales departments almost invariably have a love/hate relationship. Turning some of the questions that are asked in both groups around to match the other's parlance might make a love-fest possible.
Are there any other areas that might benefit from "refactoring"?
I love looking at a piece of code that works (for the most part) but just doesn't feel right and taking it apart and putting it back together so that it makes more sense, not just for me but for the next person who comes along.
I find it funny that refactoring and unit testing come from the same core concepts (Agile) because if done correctly, code that was properly unit tested SHOULD result in code that is pretty well-written and refactor-proof. (I'm no expert on the philosophies behind this so please comment and rip this post to shreds)
So refactoring really comes into places where you've got unwieldy code (or worse, legacy code) that no one really can wrap their head around. By the time you've finished refactoring, you possibly COULD have some ways of unit testing it (if you were able to separate each logical piece out).
So how does this apply to demos?
Depending on who is giving the demonstration, a demo will consist of the following:
a) overview of features
b) description of benefits
c) demonstration of functionality
d) explanation of functionality
e) review of benefits / explanation of results
and possibly
f) showing of additional features
The actual content differs by person:
If a sales person gives a demo, it likely goes a->b->e.
A sales engineer: a->c->f->b (possibly e)
A developer: a->c->f->d (and sometimes you don't even need a)
A trainer: a->d->c
A trained user: c
If you want to really look at a valuable demonstration, why not refactor each piece of the demonstration asking the following questions (in this order):
1. What benefit are you trying to show?
2. What feature showcases this benefit the best? *
3. What is the bare minimum I can show to highlight this feature?
4. Is the result obvious?
* If more than one feature gives this benefit "best", then you may want to rethink the design.
How does this relate to refactoring code? Re-ask the questions, thinking about code:
1. What is this block of code supposed to do?
2. How could I rename this to make it easier for others to understand?
3. Have I made this as simple a call as possible for this function to run?
4. Is the result obvious to the calling program?
Development and sales departments almost invariably have a love/hate relationship. Turning some of the questions that are asked in both groups around to match the other's parlance might make a love-fest possible.
Are there any other areas that might benefit from "refactoring"?
Comments