Software Engineering, Project Management, and Effectiveness
What's the best way to build momentum and get results? Start with something simple. Seriously. I get to see folks who get results and those who don't. The difference nine times out of ten isn't smarts. It's simply action. The smart folks who don't get results, either get stuck in analysis paralysis or add too many dependencies up front. The folks who get results start taking action and adjust along the way.
Why This WorksStarting with something simple works. It's not that thinking up front doesn't help. It certainly does. The problem is, three things can happen along the way:
The best way to fuel your fire is to incrementally get results. Start with something simple. Results feed on themselves. If you start with something small, you'll learn faster and you'll start to adapt. You'll inform your thinking.
How To StartStart with the smallest thing you can personally do. If you don't know where to start, here's key questions to help:
Personally, I find asking what I can do today to be the most effective. Time is a great forcing function. It's very easy to cut scope using time. If you don't respect time, then it's very easy to add way too many things that will never happen.
Fail FastWhile starting with something simple helps build momentum, you'll also want to quickly spike on your risks. You can do this separately, after you have some success under your belt.
To fail fast, cut your idea into thin end-to-end slices and test your results. For example, take one story or usage scenario and try to instantiate it. Even before you build the solution, simply doing a dry run will reveal a lot of questions you can use to shape your approach.
The purpose of failing fast isn't to fail. It's to uncover your risks and pick better paths.
Self-Start Techniques for the Action-challengedIf you know your pattern is to think a thought to death before daring make a move, then here's a quick way out. Here's two proven practices:
Once you get in the habit of just getting started, you'll wonder how you ever got stuck in the first place.
Success SnowballsAt the end of the day, nothing succeeds like success. Success is a snowball, so build on your successes. Good luck, and get started, on whatever it is that you've been thinking about starting.
PingBack from http://msdnrss.thecoderblogs.com/2008/02/09/start-with-something-simple/
Excellent technique....I tried and it really worked for me. I came to work and thought i can do my emails in fast and effective way so lets start it with it...I started and i was bit more productive.
Thanks for excellent post.
I know your techniques is very effective. But we always have a choice between the easy one and the right one, in the domain of getting a small chunk of job to be done. After reading your blog, people might get confused and some might also make the easy choices.
In the domain of very big product to be released, such easy choices may deteriorate the quality of the product. I think you should also consider writing on how to make the right choice for your overall success.
Hey Shoaib - great to hear! Momentum is a powerful thing. If you need a technique for clearing you inbox and keeping it empty, check out The Zen of Zero Mail - http://blogs.msdn.com/jmeier/archive/2008/01/14/the-zen-of-zero-mail.aspx
Hey G - I agree -- some people may make the easy choices. Some easy choices can certainly deteriorate the quality of a product.
I've been seriously debating writing a full-length guide on software success. I've had the benefit of meeting with a lot of experts that have been through the school of hard knocks. Personally, I've learned a lot of lessons by focusing on security and performance.
Off the top of my head, if I had to think of three things that could help folks make the right choices in building a product, I'd say:
1. Use scenarios. http://blogs.msdn.com/jmeier/archive/2007/10/15/why-scenario-driven-engineering.aspx
2. Know Kano - http://blogs.msdn.com/jmeier/archive/2007/12/31/kano-satisfiers-and-disatisfiers.aspx
3. Know what you're trading/balancing: user experience perspective, business value perspective and technical perspective.
If I could add another, I would probably say, use a Scenarios and Features matrix - http://blogs.msdn.com/jmeier/archive/2006/12/09/scenario-and-feature-matrixes.aspx
If somebody asked me for the real secret, which applies whether it's software or you name it, it would be adopting a mindset of "Time-boxes, Rhythm and Incremental Value" - http://blogs.msdn.com/jmeier/archive/2006/03/17/time-boxes-rhythm-and-incremental-value.aspx
OK, here's two more things:
- High ROI Security Activities - http://blogs.msdn.com/jmeier/archive/2005/10/11/high-roi-security-activities.aspx
- Threat Modeling - http://blogs.msdn.com/jmeier/archive/2007/12/20/getting-started-with-threat-modeling.aspx
BTW -- you can apply the raw concepts of threat modeling to any quality attribute (performance, reliability, usability ... etc.)