There are probably two broad categories of design/development that actually happens in the product based software industry. (I've not worked in the services domain, however, if u read on, you will find an interesting argument)
- Research and Development
- Test and Development
Then theres the second category of development. TnD is what it is fondly called.
Its very simple to understand. you are asked if you can "quickly" test and see if something can be done. You say, after running a few commands, figuring out some new algorithms, testing some apis, making some rough tweaks, that technically, it is possible. And thats where the "management" pitches in. Almost always, the contribution of the management chain to the technical value of a product is on the negative scale... ( i still have doubts abt the financial value, hence wont comment) if they work really hard, they can only worsen it, never make it better.
They say, what you have done as part of 'checking' whether something works, is enough! And it goes as-is into the production code.
And so, your product is considered to be 'ready' after a series of "test and development" cycles. there is very little or no formal design. Testing too, is, once again, overlooked, since you developed it by testing the same damn thing repeatedly, anyway!
In the services domain, i assume that you have projects to work on, rather than products. (you work 'with' products, not 'on' them). And that essentially forms the difference between the two categories. The development styles described are followed in a services based company too, i feel (I do not know for sure).
how i would define projects and products is : a product is something that solves a core problem that hasnt been solved before. a project is something that involves writing the business layer and hence customisez the product for a particular use case.
6 comments:
Yappa yeshtondide pa heLakke! :D
Ok start.
"RnD is when you know your requirements very well. You actually have a "design" phase only when the requirements are 'frozen', where you think thru the interfaces for the product."
Might've been true for products like ur beloved HP OpenView Suite which were "designed" and implemented a long time ago. Itteechige baro products are all Lean, agile, etc etc ankondu full rapid cycles of development, design n test (in slightly random order sometimes!)...Forget what happens in the real world, the processes themselves are all whizz!
And present day "RnD" involves fixing bugs and implementing enhancements. This statement is true for 90% of companies in Bangalore. Period. I'll go out on a limb and extend it to 95% if you buy me some vodka.
Thank you for a very good insight into the phenomenon that is TnD. Do you know if it is widely practised nowadays? Any other living examples that u know of?
And yeah, your view of the service oriented domain is also pretty accurate i thinks...of course we don't know the nitty gritties maybe...
Psst...whats RDL?
Ok ok ok got what RDL means...
i wasnt talking about any legacy product, in any way. dont read this thinking about what you know abt me.. :)
you are mixing models/methodology (lean,agile,waterfall blah and oh bleh too) with what i call the broad category of blah blah... i actually dint know what else to call it.
When you say 90% of companies fix bugs and write enhancements, well, what else do software companies do? write code from scratch? how often does that happen? and why? when everybody wants to re-use as much of code/features as possible... so, look at it this way. accept that bug fixing and enhancements are alll there is to soft dev. then try to see "how" you're doing it.
i'm sure MOST of what many of us do today is TnD. RnD is ideal and as i mentioned, very few companies go for it because of productivity loss due to adherence to process(why do u think agile came into picture anyway, trying to factor in process adherence AND meeting timelines is wat agile is about).
we're doing dirty work, basically with TnD.
AND management here(in india) supports it. Sigh.
If you can't explain further 'the broad category of blah blah' then artha agalla sir sorry...
Re-use of code/features is different from writing/making a new product. Yes ppl are probably giving out old wine in new bottles, but they ARE making those new bottles using old glass and old wine and something is new... Agreed that not much of new products are being churned out nowadays, and it is more of customization/implementation of one single set of features (to be read as a product), but reuse of features not to be mistaken with lack of new products...New "products" are coming out here n there everywhere my friend...Every new "website" that comes out is code to be maintained...They maybe re-using mysql, but they're writing something new alright, even if its just another social networking site.
"How" is a bug fixed? Depends on how fundamental a bug it is in the product, but most of them involve some sort of "investigation", and in my opinion, has very little relevance to the two "approaches" of software "development" that you are talking about... It involves an understanding of the customer's running environment, an understanding of the interoperability of ur product with potential others in the cu's env, and a suitable understanding of UR product's working and flows. It has nothing to do with "requirements" or "design" etc, atleast in the way I perceived you to have used it.
i wasnt talking abt the analysis phase. investigating the customers (i hate it wen u use cu for customer... makes me think they're copper origins :D) env, analysing the exact use-case, learning wats actually going on is still OK and has nothing to do with tnd or rnd, u cant avoid it and it HAS to be done.
talk abt what happens later, when you know wats going on. there will be two control paths that ur thinking takes.
1. whats it supposed to do (there you go! u got the requirement)
2. how to make it do what it is supposed to do(and u got the design and then further, implementation)
i was talking of these two phases specifically, design and development. what exact changes go into an existing or new product. can be bugs or enhancements. alva? not clear?
Now u're making sense in my head :) (It is an achievement that this happened, according to Scott Adams...the successful, unadulterated arrival of ur concept from ur bubble into mine!)
Yes you can look at it that way about the requirements part...Adre yen gotteno, naavu conventional aagi odiro "requirements" are much more complex, manifold and swalpa different compared to this product maintenance scenario. That doesn't take away the fact that it(how a product/process/component should behave) is a requirement...
And 2nd point i definitely agree...several approaches iratte to make a fix and to make it work...where u fix it, how u fix it will be design n imple respectively yes...
Post a Comment