the real words are always left unsaid
they get conveyed through eyes and gestures
the real work is always left incomplete
it is complete in its imperfection
the aim of life is to just give a few touches
of your own a little here a little there
Wednesday, December 31, 2008
Monday, November 17, 2008
Industrialisation in software?
One of the articles that i read had a question: Can software component creation be industrialized? That set me thinking... Software engineering has picked up many engineering practices related to Quality, Design and Productivity from other engineering disciplines. But can it also incorporate industrialization/assembly line production? Can components be created separately and then automatically assembled?
According to me, to an extent some distributed component creation does happen in software. Like in one of my earlier projects different teams created different 'parts' - PeopleSoft, Portal, Nextance, Elance, WLI components. Or the separate Model, View, Controller created by separate teams in MVC architecture and 'assembled' together in CVS. Or development using any design pattern that can reduce coupling like Business Delegate
But the assembling is not automated and it is not looked at as a time saver. About assembly lines i think they don't increase the speed of producing a single unit, but only increases rate when there are a stream of units to be produced. Since only one unit needs to be produced in software, and duplication is easy, assembly line production does not apply.
There are also, some disadvantages of assembly line/industrial production approach. It can be inhuman and tends to treat workers as machines. What if somebody is bored by doing the same thing & wants to do some other part of the work. Imagine the job of a person at assembly line is to fix three screws in a car door. Day in and day out. Agile methodology in software comes to the rescue here. One can pick up tasks that one wants to do at the start of development. If later, a person feels like doing someone elses tasks he can do it, as the flexibility is built into Agile because of the short daily meetings.
So to conclude, i am glad that software is developed and not produced!
According to me, to an extent some distributed component creation does happen in software. Like in one of my earlier projects different teams created different 'parts' - PeopleSoft, Portal, Nextance, Elance, WLI components. Or the separate Model, View, Controller created by separate teams in MVC architecture and 'assembled' together in CVS. Or development using any design pattern that can reduce coupling like Business Delegate
But the assembling is not automated and it is not looked at as a time saver. About assembly lines i think they don't increase the speed of producing a single unit, but only increases rate when there are a stream of units to be produced. Since only one unit needs to be produced in software, and duplication is easy, assembly line production does not apply.
There are also, some disadvantages of assembly line/industrial production approach. It can be inhuman and tends to treat workers as machines. What if somebody is bored by doing the same thing & wants to do some other part of the work. Imagine the job of a person at assembly line is to fix three screws in a car door. Day in and day out. Agile methodology in software comes to the rescue here. One can pick up tasks that one wants to do at the start of development. If later, a person feels like doing someone elses tasks he can do it, as the flexibility is built into Agile because of the short daily meetings.
So to conclude, i am glad that software is developed and not produced!
Monday, November 3, 2008
Architecture Diagrams 2.0
I have always liked looking at architecture diagrams and creating them using MS Visio. It is much more easier and faster to understand the system using the diagram rather then reading an explanation, especially for right-brained people like me.
But can something more be done to make the diagrams even more appealing and useful? Three things that i think can be added are interactivity, flow and prototyping.
Objects & Interactivity:
Would it not be great if the various objects in the diagram are interactive, which you can play around with, check its properties and contents. A user should be able to click on the database object, see a shopping cart object there, and on clicking on it be able to see a sample order.
Flow:
Would like to see sample data, flowing in the system and getting transformed, rather then just a static mention of data.
Prototype:
Generally a technical architecture diagram is created at the start of software development, and so is a prototype. Can a prototype be plugged into a architecture diagram, so that anyone who looks at the diagram can also have a test run of the system using the prototype and see the actual data flowing through the various components of the system.
But can something more be done to make the diagrams even more appealing and useful? Three things that i think can be added are interactivity, flow and prototyping.
Objects & Interactivity:
Would it not be great if the various objects in the diagram are interactive, which you can play around with, check its properties and contents. A user should be able to click on the database object, see a shopping cart object there, and on clicking on it be able to see a sample order.
Flow:
Would like to see sample data, flowing in the system and getting transformed, rather then just a static mention of data.
Prototype:
Generally a technical architecture diagram is created at the start of software development, and so is a prototype. Can a prototype be plugged into a architecture diagram, so that anyone who looks at the diagram can also have a test run of the system using the prototype and see the actual data flowing through the various components of the system.
Subscribe to:
Posts (Atom)