Random thoughts on the importance and of innovation in software development. Trying to reverse the process of development phases.

(Typical waterfall model and each iteration of agile model)

6. Maintenance
5. Test
4. Code
3. Design
2. Requirement Specifications
1. Innovate
In start-up mode, 2 and 6 do not exist.
So, we are left with
4. Test
3. Code
2. Design
1. Innovate
Testing is a parallel process. At the time of innovation, testing and acceptance at idea level is done.
At design level, decisions and architectural blocks are tested if all desired functionality is there and there is room for evolution.
At the time of coding, unit-testing, integration testing is done. After the product is ready, formal QA process is carried out.
So we are left with,
3. Code
2. Design
1. Innovate
Even the senior most guys or product architects are hands-on with coding. Though high-level design time and coding time are separate, detailed design happens along with coding. With shorter agile iterations, quick design discussions followed by coding happen. So, we can merge Code and Design also.
Now, we are left with
2. Design
1. Innovate
Lets plug these two also together as layman meanings are similar.
So, we are left with the one and only step INNOVATION or “I”
Basically “I” is there in each and every step.
Every small and big task associated with us has enough scope for innovation, no matter what phase of the software life-cycle we are working on.
Whether one is an Architect, Coder, QA, Sys Admin, CEO, CTO, CFO (sorry if I missed something). It DOES NOT matter.
What matters is what Innovation or “I” we add in the task, in the process, product, work flow of the organization.
Your “I” can be a GAME CHANGER for your startup.
Your “I” can be a TIME SAVER for your peers.
Your “I” can make you a STARTUP SPECIALIST.
Tagged with →  
Share →

2 Responses to “I” can make a difference

  1. Manish says:

    Even when senior most guys or product architect is coding, you CANNOT merge coding and design activities together. When you try to merge the two, we tend to design so as to avoid the first cut code, and not design to completeness. You always have to keep the design thinking time separate to avoid unnecessary delays and short-cuts in implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *