Being in the software development industry I worked in multiple projects and on the way met people with diverse mindsets. I interacted with people from the same industry but from different sectors like marketing, operations, R&D, development and people from the other industries mainly as clients having unique point views on a software development project. In the early years of my career I used to go to the client places to study the requirement accompanied by the senior members. The initial discussions were around topics like the scope of work, features of the system to be built, preferable technologies, an approximate estimation of the work and required span of time to complete the project.
Quite Embarrassing
I remember a specific situation where a similar conversation was going on with couple of representatives from the client company. The topic was on estimation and we proposed a rough estimation for the work as 30 man months (well I cant’ recollect the actual figure right now). One of the associates from the client’s side said, “When you say 30 man months does that mean 30 men can finish the project within 1 month and vice versa?” Well you can not consider all minds in audience to be of the same level.
From his point of view it’s quite a rational question, to us it was utterly unexpected. In an adverse situation like this one of our senior members attempted to explain him a bit about the complexity and dependencies involved in the trail of execution of a project, which helped us in getting out of the discomfiture. I roughly remember the project initially estimated around six months which got extended to two years; an illustration of charismatic management.
Why Can’t We?
Couple of months back there was a topic in the news that some people built a playground in a day in the city of Sanford, Florida. If the chap who asked the question to us years ago, had read this news before participating in the conversation, I am sure he would’ve an even more stalwart argument. Building a playground includes months of preparation, heavy equipment, and most important in the equation, manpower, but somehow they made it possible.
Can we do it to software projects? So that someday I could go back and tell the chap that yes we can turn the equation as
30 man-months = 30 men X 1 month or 1 man X 30 months or even roughly 600 men X 1 day (assuming 20 working days a month).
The Debate
The debate becomes absolutely baseless if we consider this figure as only the manpower effort. Should we revisit our estimation standards, methods and techniques once more? Rather provide an estimate including other factor those are involved. Apart from manpower it engages lots of other resources and dependencies on multiple factors at various phases of a project like
- Stakeholders’ interest on the scope, cost, motivation and foreseeing the future of the product.
- Availability of required infrastructure to execute a project
- Availability of appropriate skills and experiences
- Rate of attrition of the human resources
- Proper strategy to mitigate the risks caused by controlled or uncontrolled conditions
- Effective project management plan and monitoring
- Effective communication to dig out the clarity of the requirement
- Proper analysis of the requirement to map elements from the problem to the solution domain
- Time spent on researches to find technical solutions to unpredicted problems during execution.
- Suitable design of the proposed system
- Time spent on testing and rework.
- Time spent on documentation and user training.
- Constraints in deployment.
Pros and Cons
Lack of any of the above factors can lead to a delay in the route to delivery. So far we are far away from the miraculous day when we can have all the factors ready as desired at our fingertips while executing a project. Certain factors stand to be uncontrolled, for example, the clients’ interest on financing, rate of attrition and sometimes the unexpected technical hazards on the infrastructure, specially when you are working across different geographical locations. Rests of the factors are more or less controllable.
Stakeholders
From my past experiences I noticed most projects introduce delay while deciding on the scope and cost, from the stakeholders’ perspective. Once we are in a hurry things can be available right at your footsteps but then we end up with rushing into the next phases missing out essential information and the big picture, which might turn up as a big obstacle in the testing phase when the requirement shows up its new faces. A good place to loose out on time.
Experience and Skill
The human resource and skill set problem does not interfere so much where everyone is able to participate in any of the phases of a project but that happens in very few cases. Work distribution is done on the basis of experience levels and skill types. You can have more aggressive project schedule based on how efficient people you have and that’s a universal truth since the early ages of software development. With the advent of new technologies, frameworks and of course a wide variety of resources available on the internet the requirement of the skill sets are not so bad as was before but in that case we need time to learn new things. Rate of attrition is one of the natural calamities hindering the execution of a project particularly when you are lacking proper backup plan. The risk mitigation plan should take care of that. Documentation, well that’s again a time taking event, might help on the knowledge transfer for a new member.
Project management and Monitoring
Project management plans should address these dependencies and make out a critical path to carry out the project. To allocate resources the plan needs to take care of resources and their skills. This is a critical activity since all the resources do not possess identical skills and experiences. Wish they could have, so it would be far easier to allocate resources across different activities of a project and rotate them anytime as needed. Agile methodologies will surely help in close monitoring and recovering from misdirection fast. The advantage of a member acting in versatile roles surely keeps agile processes one step ahead. A vital strength for the small companies with small set of resources. Sometimes working on a small part of the product for a member might bring a miasma on the entirely of the product and its requirement. It restricts the future oriented thinking for a team of developers. Members of a team following agile sometimes end up working in silos.
Are we looking forward to have mix and match of our old methodologies (e.g. Waterfall, Spiral, Iterative, RUP etc.) and the agile ones (e.g. XP, Scrum, Crystal etc.)?
Study and Analysis
A proper communication during requirement study and analysis phases could save considerable amount of rework during the testing and implementation phase. A little bit of experience, psychology and technical expertise help the players in this phase to get into the heart of the picture that the client/user carries in their mind. After all it’s a human to human communication; thank God we don’t have to deal with psychology with a computer. An expressive analysis document saves a lot of time in design.
Construction
The construction phase usually constitutes of architecture planning, design, development and testing. It involves research on new technologies, designing and construction of components and testing the same. With the coming storm of ideas, products, open-sources and buzzwords it’s hard to select an appropriate technology these days. A project should consider the time for this as well and try to minimize as much as possible. A proper technical guidance of an architect toward a structured approach of development can speed up the development process. Selection of an appropriate technology, a bird-eye view of the design, recognition of patterns and a proper introduction of the same, reusability of pieces, adherence to standards during development can be well controlled by an architect, so that you don’t get face to face with re-factoring or re-designing quite often. Another most important thing is to figure out the expectations on non-functional requirement of the system and make out a plan to address those. People without prior experiences with automation are often reluctant about discussing on the non-functional requirement at the initial phase of study.
Designers are of course confined within the scope sketched out by the analysis but if they try they can still foresee the feasible enhancements of a product and design it to be flexible enough to accommodate the changes in the future. You never know, some of the enhancements can be at your doorsteps during the testing and deployment phases. They can make it expressive enough to ease the implementation for the developers, which minimizes time.
Testing and rework is the most important phase where the product actually gets weighed against the requirement and that’s where the time gets more and more elongated. This is quite a normal phenomenon in all most all projects and the target is to eliminate the rework cause by a misinterpretation of the initial requirement. Preparation of test plans parallel to the requirement analysis often helps.
Sometimes a gap is noticed in development and deployment environments (where your product is installed) causing a delay due to rework or configuration in the deployment phase. The preparation of a concrete deployment plan during the architecture or design phase helps in trimming down the time. Specially in a geographically diverse location, on heterogeneous platforms or a scenario where multiple preexisting systems are involved.
Tangible and Intangible Hurdles
We understand that there are ample of reasons why the time taken for a project can not be shrunken as desired. We have controls over the tangible elements involved in the process of execution, for example,
- setting up infrastructure
- usage of tools in various phases of design, development, testing, deployment
But intangible factors are not entirely controllable such as
- Stakeholders’ interest
- Skill of human resources
- Rate of attrition
- Time to map requirement into features of the proposed system
- Time devoted to research for finding out a suitable software/technology a for a given problem
- Time to think and come out with a proper design applying experiences
- Time taken in grasping a new technology or open-source product to use it during development.
So much of thinking processes involved in the entire path and how do you estimate your thinking process, well we don’t have a “Thought point analysis” (like function point analysis) yetJ. Do we have to evolve with an agile method of thinkingJ? We can even minimize the transformation of the thoughts from the user’s mind to the analyst’s mind and then to the architect’s and the designer’s and the developer’s and so on, but how?
Honey I Shrunk The Kids
The Agile method of thinking is not yet in the picture though but specially being in the software industry we are quite familiar with abstraction. From machine languages (first generation) to assembly languages (second generation), from assembly languages to high-level programming languages (third generation e.g. C/C++, Java, PL/I etc.) and then to English like natural languages like SQL (fourth generation) and finally to the graphical interfaces (fifth generation) like integrated development interfaces (IDE) for planning, design, development and most of other areas like requirement capturing, testing. These tools intake the thoughts from the human minds and translate them to other languages like C/C++, SQL, Java etc. The pains of programming in machine or assembly languages have be removed by third generation languages. IDEs made the pain of writing C/C++/Java codes quite easy. We are even thinking about Domain Specific Languages (DSL) to keep up the movement one step ahead. I look at SQL being a DSL for database operations. The history of software development shows us an approach toward reducing time for faster and easier development process, at the same time standardizing solutions.
So now we have our helper friends as Abstraction and Code Generation. Though the term “code generation” has picked up during the last couple of years with the conceptualization of Model Driven Architecture (MDA), the basic concept was there from the beginning when we learned to design compilers. Only thing is that, we are thinking in a step by step manner to reduce the gap between the user’s requirement and the end product shrinking the time of development. Open sources are a playing the lead role in reduction of cost and speeding up on time with reusable standard solutions.
We are even thinking of automation through out the entire process transformation of thoughts at different phases of development and reaching out for business process management (BPM) and modeling. BPM enables us to grasp the thoughts right from the minds of the user and turn into code. Well not exactly, we still have rooms for an architect, a designer, a developer and a tester. I don’t understand why we are trying to address the domain and the business processes separately from different angles of BPM and DSL. If you are given with a graphic interface to build your process model and generate code out of it, would you take the pain of writing the same using a DSL? A good use of DSL could be defining the tits and bits of the business process after you have modeled and generated it using a BPM tool. A BPM tool is of course a good tool to address the issue integrating your new systems with old ones irrespective of the platform they are built on. Reusing the existing systems is now far easy with the advent of Service Oriented Architecture (SOA) and that too auto-generating the code for that.
We can certainly imagine the day when one can generate the entire solution in a single day sitting on his/her desk alone. I will have to repent on that day for not keeping the contact number of the chap who asked the question year ago.
