Does automation really beget discipline and uniformity
Call it good advice or bad, the earliest influences on my programmer mind told me that requirement, design, implementation and redesign followed a vicious circle ?
Simply put, a requirement raised by a user 'seeds' the design. The design refines the requirements sometimes and finally things get implemented (hopefully !). The implementation sometimes pulls back on the design and requirement too and the give n take continues until someone gets bored and puts it on production !
After a while, age ( or bugs !) catch up and the piece of software undergoes a 'change' or a redesign. The lifecycle of the previous round of requirement/design and implementation haunt the current round like the shadow of a ghost from a stephen king movie :-) ..
The unwanted fallout is that the software gets embedded in the users' psyche so deep, that he never escapes from it's shadow and his mind goes around the old software while he's thinking of the next round of development he needs. It shackles him without him knowing it. It becomes the 'religion', the anchor - around which he's trapped.. the software becomes the 'business process' instead of the original intended evolution..
The 'good' fallout is that this psyche is infectious, and with this user's career path, job changes and network, the idea propagates and catches momentum to become a standard of sorts..!
Even the developer keeps following the 'safe' design everytime he needs to implement something similar anywhere else..
That, friends is what passes on for uniformity and discipline in the world of programmers.. :-)
PS : No offence intended to my comrades !
Call it good advice or bad, the earliest influences on my programmer mind told me that requirement, design, implementation and redesign followed a vicious circle ?
Simply put, a requirement raised by a user 'seeds' the design. The design refines the requirements sometimes and finally things get implemented (hopefully !). The implementation sometimes pulls back on the design and requirement too and the give n take continues until someone gets bored and puts it on production !
After a while, age ( or bugs !) catch up and the piece of software undergoes a 'change' or a redesign. The lifecycle of the previous round of requirement/design and implementation haunt the current round like the shadow of a ghost from a stephen king movie :-) ..
The unwanted fallout is that the software gets embedded in the users' psyche so deep, that he never escapes from it's shadow and his mind goes around the old software while he's thinking of the next round of development he needs. It shackles him without him knowing it. It becomes the 'religion', the anchor - around which he's trapped.. the software becomes the 'business process' instead of the original intended evolution..
The 'good' fallout is that this psyche is infectious, and with this user's career path, job changes and network, the idea propagates and catches momentum to become a standard of sorts..!
Even the developer keeps following the 'safe' design everytime he needs to implement something similar anywhere else..
That, friends is what passes on for uniformity and discipline in the world of programmers.. :-)
PS : No offence intended to my comrades !
No comments:
Post a Comment