05 Nov 2009
“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.
I am a huge fan of Alan Cooper and personas…huge fan. I have written at length about him and his techniques here, http://benjaminhysell.com/archive/2009/02/alan-cooper/. My goal in this article is not to cover the basics; other blogs and books cover the basics of personas. Rather, I hope to cover why I use personas, and why I have embraced them.
So, why do I love talking about personas and using them for quoting, specifications, and development work?
Fear.
::No wait, I’ve used ‘Fear’ already as a motivator for using Test Driven Development here: http://benjaminhysell.com/archive/2009/08/tools-in-the-toolbox-test-driven-development/. I can’t just keep throwing around the same emotions…I had better come up with something different…::
Take two.
One reason.
I hate designing software for the person named “user”.
Think back to the last meeting you were in with your developers.
I have a great new idea for your blog website! I think some of the users who use your website get lost in the technical jargon you use. Let’s add a whole section that explains all of the technical terms that appear in your blog entries on the right hand side of each page. That way when people come up against a new word they don’t know they can just glance to the right side and see a definition!
This actually isn’t a bad idea on the surface. When my non-technical friends read my blog they may walk away with something more than just saying, “Wow, you write a lot of words!”
Then another developer chimes in…
Let’s build an iPhone app that links back to this blog! Every time you publish a new article it’s automatically sent to the user’s iPhone, they get a notification that a new article is up and their phone will “ding” with a new article notification!
Again, not a bad idea…technically possible, would be kind of fun to implement, figure out the whole push notification framework. Yes, that is a project I could lose myself in for a while, and in the end it would be sort of neat to have figured out all of that technology and to get something working.
Here is the rub, although each idea is fun, interesting, and very technically possible, neither one does anything for the core function of my blog. Neither idea helps me write about managing people, software, and projects. Nor is either idea squarely aimed at my core audience, other developers, project leads, and managers.
By using personas I can quickly and easily figure out if either idea is worth while exploring and implementing.
How you may ask? Simple, I can quickly take every idea I have for my blog and ask myself,
If I had an iPhone app that notified John that I had published a new article would he use it? Would it be worth the effort to publish such an app, and would John tell his friends about it? Would John pay for an app like this?
Who is this John? Good question…
Before going any further let me introduce you to John.
Name
Age
Personality
- Enjoys going out with his friends for weekly “Man Night” where many wings and beers are consumed
- Plays sports year round, golf in the summer, hockey in the winter
- Stays up to date on the latest technologies by reading whatever he can get his hands on
Skills
- He is his families IT go to guy.
- Loves learning new programming languages for the challenge of it
- Enjoys manual labor after a long hard day of pushing pixels all over the computer screen.
Goals
- Desire to own his own company some day
- Realizes there is more to staying competitive in the market place than just knowing the latest software frameworks and architectures, hence he is reading outside of his field to learn how to do marketing and sales.
- Aspires to have his own technical blog
Attitudes
- Loves all forms of technology
- Willing to be the first one to try new operating systems, development techniques, and be on the bleeding edge of all new technology.
- Has a hard time stepping back from the computer at night since there is so much to continually learn.
John seems like a pretty good guy. The sad part is he doesn’t exist except for me to test my blog topics, design decisions, and possible iPhone apps against to see if he would like them.
John is my sounding board. John replaces all instances where I might go, “Would the user like this?” Now all I ask is “Would John find this useful? If I spend time on this would John tell his friends to check this out?”
Designing my blog towards a someone, a real defined someone, helps me figure out what I should do and keeps me focused on my core audience. Remember that iPhone app? John wouldn’t need it, John would be using RSS to keep up to date with my blog.
What about the jargon pane on the right hand side of the site? John probably knows the jargon already, and if he doesn’t, i.e. its something new to him, he is going to be motivated enough to go look it up himself using Google.
I love writing for my wife,
::Thanks for proofing this for me!::
but if she comes across a term she doesn’t know she will likely use the surrounding paragraphs to figure it out or skip it all together. I don’t care if she doesn’t get the whole article because she isn’t my core audience.
John just saved me hours of time implementing ideas for a “user” who isn’t going to read my blog.
For every project I sit down and define who my end users are for that project before I start. Each one gets a name, age, personality, skills, goals, and attitudes creating a vivid image of the person I hope will be using my software. Every decision I make, be it user interface or back end operation I ask,
Will John like this new feature? Can he even use this new feature given his skills? With his attitudes would he want to use this new feature?
I instantly know which features I should implement and which ones should go back to the drawing board. Personas have become my strongest tool for designing software that people actually want to use.
Next time you get in an argument about an implementation detail or presentation issue ask out loud, “will our main user Steve actually like what I am creating for him?”
When a developer asks to implement this crazy new login procedure ask them, “Will Sally, our 75 year old grandmother who is our main user be able to figure this out?”
Bring real people into your development and you won’t be disappointed with what they tell you about your software or new idea.
03 Nov 2009
“Breaking Down the Game Film” is a term commonly used to analyze tape from an already played sports game to dissect what went right and what went wrong. In this series I’ll be taking published articles from around the web and break them down.
Topic: Mission Statements
Article: “How to Write a Mission Statement that Isn’t Dumb”
Link: http://www.fastcompany.com/magazine/140/do-something-wordplay.html
Short Summary: The time used to generate most mission statements would be better spent burning $20s in the alley behind your office building. Identify your company’s quantifiable goals and write a statement that will inspire people to rally behind those goals.
Analysis:
Quick! What is your company’s mission statement?
Can you find it on your internal website?
Can you find it on their external customer facing website?
Ok, now that you have found it how do you feel? Quick, one word!
I’ll spot you the word, let’s go with underwhelmed.
Now, compound that feeling with the thought of how many man-hours it took to produce that mission statement.
It’s ok if you are now openly weeping…let it out. I know your company couldn’t buy you that brand new computer chair last year, they had to write a very bland statement that serves no purpose to you or your daily life. Sure, the new computer chair would have been nice, but they really needed that sentence on their website.
Before reading this article I wouldn’t have given a company mission statement a second thought. One of the tools I use, Microsoft Team Foundation Server, a task tracking and source control system, starts every project with a few pre-populated tasks. One of those tasks is to write the project’s mission statement. I normally skipped this step; I never saw any value to burning any calories on attempting to define the mission statement for an individual project.
However, after reading this article something clicked for me, making me reconsider the value of the mission statement.
Do you want to add a feature to the project? Will that feature further project development? Does it mesh with your mission statement?
Yes: Continue investigating the idea.
No: Drop it and move on with your life.
Quick and simple.
Caution.
Like any tool in your toolbox overuse the mission statement and your co-workers will become numb to its effects. Engineers smell b.s. from a mile away, if you show up Monday morning chanting your company’s mission statement, wearing a shirt with the statement on it, and hand out pictures of you posing with the mission statement you will lose them. “Sure boss, great idea, I’ll put on my hat with the mission statement tomorrow…today it would clash with my outfit.”
If you are going to take the time to do so, write the mission statement with care, capture that goal, write it in such a way as to inspire people to work towards that goal, but be sure to not over use it.
31 Oct 2009
“Tools in the Toolbox” is a series of posts on development and design tools I use on a daily basis.
You use source control, right?
Good, I’m not going into the benefits of using source control, it should be a no brainer in this day in age.
No, you don’t use a system to back up every revision you make to your code?
Ok, here’s what you are going to do.
- Finish reading this blog post and then never come back to my blog again.
- Close your browser
- Uninstall all of your development tools and never write another line of code.
I’m not kidding. If you are not using some form of source control for your daily coding activites I’m not sure we can be friends any more. I mean, before I learned this about you I thought of us as at least friendly, but this is a deal breaker.
All snarkiness aside, source control is one of those fundamental tools like a hammer or screwdriver that needs to be in your toolbox. Having a system that allows one to go back in time and see every change that has ever been made to a piece of code is invaluable.
Are you telling me you wouldn’t want to time travel back in time given a chance? I’m offering you that opportunity to do so without the need of a DeLorean or a Flux capacitor. You would turn down time travel? Sir, I must say good day.
Won’t stop reading eh? Maybe there is hope for you yet…let’s look at two scenerios, one with source control and one without.
It is 10pm, you should have been home hours ago. Diner is cold, wife is mad. You are in the office, your hard drive died at 4 this afternoon. You have lost all of your code for your presentation you are going to give tomorrow, and you are only half way done recreating all of that code. You have a long night ahead of you.
Try that same situation, but this time you and I are still friends because you use source control.
It is 5 pm and you are sitting down for a nice meal with the family. You had a rough day in the office, your hard drive died right around 4 pm right after you put the finishing touches on your presentation you are giving tomorrow. Since you use source control you have copies of all of your code in a repository on a seperate server. You contact your IT guy, grab a spare laptop, connect to the source control server and pull down all of the code you have been working on. You check it over, its all there. A minor emergency before your presentation, but luckily you have avoided a full night of rewriting all of your code, and can go home and relax. Thank goodness for a good source control system
Contrived? Yes, but still proving the point of having copies of your work in a system off of your main development computer will avoid disaster. Sure, you could have avoided this scenerio if you just stored a copy of your code on a thumb drive or a network drive, but then you would lose all of the benefits a source control system brings to your development environment, each done with only a few clicks:
- One click check in process – Most systems now a days integrate directly into your IDE. With a few clicks a copy of your code is placed into the system. Total time, five seconds, max.
- One click get the latest copy – When working on a team often times people make changes you’ll have to get a copy of. Instead of bothering them you can normally right click on your project and select ‘Get latest’ to pull down the latest copy of all of the code stored in the system.
- Compare – Allows you to take the copy of the code you are working on and compare it to the code that is sitting in the source control system for changes. Did you accidentally erase a key section of code and then re-save your code? Compare it and pull back that key piece of code.
- Merge – Are you working on the same piece of code your buddy is working on? Who has chnaged what? One click and the source control system can help you merge his changes with yours.
- Shelve – Are you working on a cool new feature only to have an emergancy bug crop up that needs addressing ASAP? Take your code and put it on a shelf in the source control system. Shelving code takes a snap shot of your current code and places it in a special area allowing you to go get a new copy of your code from the repository, fix the bug, check in the changes, and then go and get the code you were working on, apply the changes, and then continue on your merry way, saving time and energy.
- View older copies of your code – This is the “Back in Time” scenairo, you need to see changes made last month to a key algorithm, with a source control system you can go back and grab those changes since you are saving a copy of every change ever made this isn’t an issue.
I use source control for everything I write, code or otherwise. Every document I write for this blog is backed up in a source control system.
For the sake of our friendship, please go and grab something, anything to put your code into. I am a huge fan of Team Foundation Server from Microsoft, but SVN has been growing on me. There is a huge list of systems out there, pros and cons, if you Google for them.
Take a hour, download a source control system, set it up, and move all of your code into it. You might not thank me today, or tomorrow, or the next, or even late next year. Some day, some day in the future, you are going to rely on that source control system and you will be thankful you have it.
15 Aug 2009
Tools in the Toolbox is a series of posts on development and design tools I use on a daily basis.
I am a huge fan of Test Driven Development (TDD). See my series I wrote for the Viewpoint Systems eNewsletter centering around TDD and LabVIEW:
Part 1
http://www.viewpointusa.com/newsletter/2008_november/newsletter_2008_nov2.php
Part 2
http://www.viewpointusa.com/newsletter/2009_january/newsletter_2009_jan2.php
Part 3
http://www.viewpointusa.com/newsletter/2009_february/newsletter_2009_febtdd.php
Part 4
http://www.viewpointusa.com/newsletter/2009%20March/newsletter_2009_Mar.php
Although I’ve written the most about my LabVIEW TDD experiences I use TDD in all of my development endeavors, be they text based in the .NET frameworks or web based development with JavaScript. Now a days almost every modern language has a framework available to facilitate test generation and automatic test execution.
One of the first things I do when I start with a new language is to find the TDD framework and take the language and the framework for a spin. No longer do I bother to create a ‘Hello World!’ app, I dive right into writing tests. My last two language adventures involving Objective-C and Ruby on Rails attest to this fact.
However, as I sit here and write this post I already hear the groans emanating from a lot of developers,
::Put on your best Sean Connary voice from Celebrity Jeopardy on SNL::
You see here Benjamin, I’ve tried a lot of development processes in the past, paid a pretty penny for them, I don’t mind telling you, for books and classes and whatnot. None of these processes ever work. So, I’ve got to ask you, will TDD really make my code better? Does it really work man?
As long as there no follow up questions, then yes, yes it does work.
Post over.
Oh, you are still here?
::Damn, now I have to come up with a few explanations…::
Why have I embraced TDD and given so much virtual ink to it?
Fear.
Out and out fear.
Back-story:
When I started with Viewpoint out of college I had endured my share of ‘larger’ software projects. I say ‘larger’ because when you are snot nosed kid in college taking a semester to build a compiler it feels like a large project. The late nights, the team of people toiling away on the code, and all of the social events missed as we attempted to get the compiler code to compile…we felt it was a large investment of time and resources.
I learned a lot on that project, but as with all college projects, once the semester was over I would never have to revisit the code base again.
Let’s face it, when you are on a co-op, one is only engaged with a company for maybe a three month period; there is rarely enough time to finish even a small project, let alone start a new one and then go back and make changes to your original project. Thus, the idea that one might have to support and modify their code at a later point in time was a foreign concept to me leaving college.
Naturally, things quickly changed once I entered the real world.
I’ll put you in my shoes as a young developer: There you are, its 3:30 PM on a Friday. Your software is crashing for some unknown reason, and you desperately want to be out of the office because it is one of the last weeks of summer. Nothing has changed in the code. Sure, you made a minor modification this morning to about a dozen code files, but the software was up most of the day, and now all of the sudden something is very wrong. Your software is stopping and starting every couple of minutes and you can’t leave until it’s fixed. You can’t just drop the changes you made this morning because those changes had fixed an even larger problem in the code, and by the way, do you remember where you made all of those changes? You wrote them down, right? You are using source control so you could roll back everything you just did, correct?
Picture yourself in a cube with flop sweat all over you realizing this isn’t how you want to run your career for the next 50 years, living in fear of every little minor change you make to a code base.
This is the realization I quickly came to soon after I started supporting some of my own code. Forget supporting other’s code, this was my own code, I wrote it and it was still acting up on me. I vowed that day to never live in fear again of modifying my code and not knowing what the results would be.
Fear motivated me to seek out a methodology that would help me avoid these types of situations. I wanted to know when I was making a code change that change didn’t have an unforeseen ripple effect through the rest of the code base. For me, TDD provided an avenue to help me avoid these situations by forcing me to generate a full suite of regression tests that I could quickly and easily run against any changes I made and validate I didn’t create any new bugs while fixing the code.
TDD isn’t perfect, and it isn’t free. Can you make sure all of your test cases exhaust all possible inputs into your system? What about the time spent developing the regression test suite? How about the time spent maintaining and fixing the test when you make changes to how your code works? All of these items have a cost associated with them.
It is near impossible to put a monetary value on the time and money one can save from using TDD. How do you quantify,
“Because I had regression tests I could run on my code the change I was going to make this morning never made it into the system because it broke all of the tests. I re-architected the solution, ran the tests, and the new solution hasn’t caused us four hours of downtime.”
How can one say their design methodology prevented a massive loss of time later down the road when you never experience that loss? How can you really prove you can save time and energy with TDD?
In my travels so far I haven’t found a convincing argument that the time you spend writing and maintaining test cases saves time and money. Basically, I have yet to acquire a DeLorean…sure I have the flux capacitor, but I don’t have the car to put it in, drive Back to the Future, and prove that if I didn’t have a regression test suite I would be in a world of hurt six months down the road while attempting to make a minor change.
Sadly, I believe one has to develop flop sweat a couple of times in their career before they will actively seek out a methodology like TDD and start applying it to all of their development endeavors, regardless of the inability to show a future cost savings.
10 Aug 2009
I’ve finished reading my Dilbert book and have kept my next book firmly planted in the ‘fun summer read’ category. Although I’m just starting Rigged: The True Story of an Ivy League Kid Who Changed the World of Oil, from Wall Street to Dubai
by Ben Mezrich, I can already tell it is excatly what I need for these long summer days. Check out my initial thoughts of Rigged in my updated bookshelf: http://benjaminhysell.com/my-bookshelf/.