+972 52-548-6969
All the pieces of a feature
One of the interesting* tidbits I learned is that just having an idea about a feature is far from being able to actually do something with it. Hell, even implementing the feature is just the first step in a very long road.
* Read: annoying instead of interesting.
Here are the things that you need to do just in order to actually call a feature Ready To Show (vs. Done **):
- Implement backend.
- Expose over the wire.
- Write client API.
- Create user interface.
- Distribution (replication/sharding)
Those things are just what you need so you can actually show something meaningful, rather than a bunch of code and a lot of hand waving. This can be pretty annoying at times, mostly because it puts a lot of work that has to be done before we can actually show it to people.
** And just because people will ask, to get to done you need:
- Logging
- Monitoring
- The ability to test easily
- Performance trials
- Longevity trails
- Production proofing
I’m probably forgetting a bunch of stuff, but those are what pops to mind.
The nice thing about getting to show something is that we can usually parallelize the work for the all of those by handing this to different people.
Comments
Something I indeed learnt during the last decade, is that only 30 to 35% of the global effort goes into the features themselves. Hence the bulk of effort is dedicated into the requirements surrounding features: performance, ergonomy, integration, code maintainability, API, documentation...
But this significant cost is precisely what makes the difference to get a professional product that people are ready to pay for.
How many Microsoft employees does it actually take to change a lightbulb?
From Microsoft Insider: http://blogs.msdn.com/b/ericlippert/archive/2003/10/28/53298.aspx
I'd always tell these people the same thing -- if it is only five lines of code then go write your own ActiveX object! Because yes, you are absolutely right -- it would take me approximately five minutes to add that feature to the VBScript runtime library. But how many Microsoft employees does it actually take to change a lightbulb?
•One dev to spend five minutes implementing ChangeLightBulbWindowHandleEx.
•One program manager to write the specification. •One localization expert to review the specification for localizability issues. •One usability expert to review the specification for accessibility and usability issues. •At least one dev, tester and PM to brainstorm security vulnerabilities. •One PM to add the security model to the specification. •One tester to write the test plan. •One test lead to update the test schedule. •One tester to write the test cases and add them to the nightly automation. •Three or four testers to participate in an ad hoc bug bash. •One technical writer to write the documentation. •One technical reviewer to proofread the documentation. •One copy editor to proofread the documentation. •One documentation manager to integrate the new documentation into the existing body of text, update tables of contents, indexes, etc. •Twenty-five translators to translate the documentation and error messages into all the languages supported by Windows.The managers for the translators live in Ireland (European languages) and Japan (Asian languages), which are both severely time-shifted from Redmond, so dealing with them can be a fairly complex logistical problem. •A team of senior managers to coordinate all these people, write the cheques, and justify the costs to their Vice President.
Yeah, writing the feature is usually 5% of the work involved. I think Deployment is missing from the list - it's something usually overlooked and can be a 5 minute job or a week-long nightmare if you need to deploy over a range of servers without the proper infrastructure in place.
Comment preview