Assembly Line Software Development - A post lean method

Most of the trendy software development methods stress on either a process or documenting rigor rather than development rigor. Agile methods were able to solve this problem to some extent, but there is still a compelling need to ensure that we deliver the working software on-time with a simplistic and convenient way. Unified Processes and Agile Methods talk about chunk of working software (executable) to be delivered at the end of each iteration. After follwing unified processes, agile processes for quite a long time I have seen them failing - though there are explanations of the failures by the respective methodology advocates. While I was working on methodologies I liked some of the features of many of them and tried to fill the still-existing gaps by something of my own. I am going to list these in a form of principles. At the end I tried to devise a simple to follow and nonintrusive methodology aimed to execute rapid software delivery, which I named Assembly line software development for the time being. Assembly line was sometimes considered to be the wrong metaphor for software development - for me it depends how do we map the subject with the metaphor and I so far I have found 'Assembly Line' as the right metaphor for the way I am going to explain. The principles are not exhaustive so far and have influence from 5 broad sources 1) Guy Kawasaki books mainly 'The Art of the Start', 2) Mary and Tom Poppendieck's Lean Software Development, 3) Agile practices, 4) Unified Processes and 5)Pain of seeing failure in many projects following RUP, XP, SCRUM.

Principles:

1. Minimizing the process rigor is one. The process should be simplistic and just to ensure on-time delivery of working software. The process should be simple enough to practice. The simplicity will make the process habitual to the people use it and should not be felt as something intrusive.
2. Make meaning: do only those things that makes meaning to its users. It means figure out the way to add value. This is influenced by Guy Kawasaki and Poppendiecks.
3. Communicate & Collaborate effectively - use better communication tool that can keep the entire team in sync without disconnect. Traceable wiki, blog and IM comminication is examples of preferred communication and collaboration mechanisms. Team management along with the team should have a good policy and practice of using them regularly. Maven kind of build+management tool is also preferred to be used in collaboration. Some features like site, distributed build management are wonderful features.
4. Continuous integration - the heart of agile processes I liked it much - it is fun doing when automated.
5. Regular demonstration of working software, unit demo and integration demo - only unit test is not enough to certify 'development done' but a working demo before the review committee is a must.
6. Assembly line oriented development where everybody will contribute to one or another assembly line. There can be several assembly lines in tree structure. The root of the tree is the final assembly line and will deliver the final and complete software. Each assembly line will have different time bound slots that is a task to be done by a person - a single task - a single person (pair programming can also be applied). The deliverable(s) of a child assembly line will take part in the parent assembly line or higher in the hierarchy. This is fundamentally different from the concept of iteration or sprint in scrum. It is an open source style software development. This is more of a work pattern recognition from opensource project styles.
7. Just start working on the mission even before the goal is finalized.
8. Disposable and cooperative component based architecture: Huhh.. we have heard and worked much on reusable components but what is disposable component based architecture?? Well I'll first talk about an analogy and then will try to explain it further. Visualize a modern village, unlike multi-storied township or city-hubs, it has independent houses and bungalows; well connected but independent. The most important point is - that want to point out is - you can dispose an 'independent house' from a 'modern village' without affecting anything in village systems. In this method - I see 'independent house' as the 'disposable component' and 'modern village' as the architecture - the 'disposable component based architecture'.
9. Need for a 'real leader', a no-non-playing captain: A real leader is must in this style of software development. A non-playing captain is real no here. A real leader is not who is PMP certified or six-sigma green belt - they may have real value in some other situations/scenarios - but who 'at least' has good knowledge on technologies; technologies to work on and related complementary and competitive technologies. I said 'at least' because in a given scenario domain knowledge might be required, in those cases the leader should be knowledgeable in domain as well. Or at least a person who is keen to learn the domain fast. The leader should be able to drive the team - consider himself as one member - for 'active learning'. More explanation in active learning is given below as one of the principles.
10. Active learning: The team should always learn - learn new technologies, related technologies (complementary, competitive), relevant domains... so on.. But while learning the learner should not idly learn rather s/he should learn actively - meaning learning and doing. If it is a technology a proof-of-concept in parallel with learning, for domain - presentation (why presentation? as this method stresses on demonstration - demonstration helps in many ways; proving that you are working, and keeping the team vibrant and fostering a learning culture) of understanding and other tutorials etc.
11. Start writing code even before you understood how-to-do fully. A minimum level of what-to-do understanding should be good enough to start immediately,
12. Fill up the gap proactively - if any of the party you are depending on is delaying in giving the input about what to do - you must try to fill the gap with your own understanding rather than waiting and wasting long time; meanwhile right escalation must be triggered for the delay. Once you filled up the gap that can be communicated to the relevant/responsible parties to get approval.
13. Round table workshop: It is good to sit together in a circular table with laptops and working while having some little discussions; this will keep the team focused on what is being done - i.e. on the delivery. The team members should participate in the table at least for 2/3 hours a day; they can obviously go back to their desk or cabin whenever they feel there is a need for working alone.
14. Delay in decision: Like it is in lean method with emphasis on continuous work; meaning - the project team should start working even before the ultimate decision made by various stakeholders about how the software should look like. Here plays the role of situational leaders (explained later).
15. Situational leadership: Every team member should be situational leader - and lead the team at the right time. A situational leader is one who drives the team to do right things before the big-bosses has made up their minds.
16. A process champion - identified in a round robin fashion - who will make sure the communication and collaboration is happening in a right spirit and all the stakeholders are participationg in it. This is role is kind of evangelist's role, who will encourage people to use right communication and collaboration tools throughout the day.
17. Delivering real-value to the community: It is too philosophical, but I think everybody will understand it. Just don't do something for the sake of just-earning fat cash, but do it by delivering real value to the customer and community.
18. Build asset - I am not going to explain much about this just follow the way opensource houses build asset.
19. (To be re-arrange the above points and continue adding)
    

Hibernate (ORM) Debate - Good or bad

There are people those who hate ORM based application. Of course there are reasons for it. Personally I like ORM - again of course for some good reasons. Mostly, the people who dislike ORM, blame it for its performance. Of course there are some performance issues while using ORM - largely due to the paradigm-rift between the two worlds - object oriented and relational. But this issue can be solved - can be solved almost (if not all) entirely. The question now is how easy to solve this problem. We will see this soon in this post. When we talk about its advantages and disadvantages we tend to forget the intention of the ORM tool. To get the benefit - it is to be used in the right context where it is intended to be used. Lets see the right context. Relational technology is good for database i.e. information store, retrieval and management. Over time relational technologies got maturity and stability and most importantly it has become standard and created industry wide standards like SQL. Simply, for database - relational technology is the best - so far. For data centric application - most of the times there is a need for data model and the data model can be well developed with the relational paradigm in mind. I.e. laying out tables and their relationships. There is another important thing - i.e. Objects. Why it is required? Real world better understands objects such as a pen, a chair something that exists in the real world. To deal with real world objects we need domain model or may be in general an object model - rather I would say - it is better to use domain/object model while dealing with real world objects. Now we have two things - one is data model and other is object/domain model - two different paradigms - two facets of application development - and both are important. We need to take care of both of the facets in the direction of their implicit requirements.

Hibernate - or a good ORM tool - sits in between these two paradigms in order to connect the best of both worlds - the object world and the relational world - meant to solve two distinctive but related faces of real life applications - object oriented technologies and relational database technologies.

The major advantage of using Hibernate like ORM is to let application developers to think about business objects and largely automates the database related stuffs.