Yet repeatability, reusability and predictability are illusive goals sought to be achieved by many software development houses for decades now ..... new fads replaces old ones, new methodologies replace old ones, new standards replace old ones and new tools replace old one .... each time with significant improvements, admittedly .... problem is often not with the new stuff coming in but rather the hype associated with it .... invariably, it fails to live upto expectations of business houses at large; especially small & medium houses which are focussed on delivering rather than moving on the bleeding edge of technologies ....
They do not have neither time nor money to spend blue sky researches ....... after all, aren't engineering houses meant to run their businesses based on already researched, proven solutions? .... is not research more close to science .... may be, science of engineering or technology .... still research is scientific activity .... why should a small business house spend time on research with many unknowns?
In many of my assignments related to architecting, I find practioners struggling to calibrate a standard or derive their own across many projects .... variables across these projects are many to allow any reasonable calibration .... the kind of technology they work with (client/servner, J2EE, .Net etc), the development team concerned (their skills, experience vary significantly even within an organization), process followed (especially considering that it evolves the individuals, teams and the organization learns) ....
How much is the rework happening? how much of earlier work is being reused? no mattter, whether it was intended to be reused in the first place or not .... what is the work involved in learning and tweaking as required? what is the impact of such changes? how much familiar the team is with the technology? process followed?
I am aware that these questions are answered in the methodologies? but how much of it is actually practised? .... the point is the moment we talk about a methodology, what follows is a ritualistic adoption .... somewhere down the line, focus shifts to either following the process (or at least, pretending to .... and thereby creating a lot of overhead) or dumping the so called process
The point is, if we have to take engineering to software industry ..... many of what is claimed as engineering has no engineering in it; it is more of a research work... it is hightime that it comes out of intellectual, academic echelons .... beyond the hypes and jargons ... which is what I am striving for in my consulting assignments
