Software development has been going on since five decades now, yet you will be surprised to know that – 4 out of every 5 application built is a failure.
Research have shown that...
Does your software fall in the list of 4? Are you building applications that require your continuous attention and make you spend all your time applying patches and re-working again and again on the application, to meet changing requirements with the passage of time? Have you become a slave of your own product? Do you always end up with cost and time overruns in every software development project? That is where most software developers end up positioning themselves.
Why such a high failure rate?
Look at the negatives listed below and you will find the answer.
The negative traits listed below are prevalent amongst most software development teams and is the recipe for failure. Give time to ponder over these seven negatives and how you can overcome them, and success will come your way.
Haste makes waste – something we learnt in our school days. Yet, even after we have grown up we do not put it into practice. Software built in haste is destined to fail and be eventually thrown in the waste bin.
Most development teams are forced to work against often unrealistic time and budget constraints. There is continuous pressure from the management to complete the project within unrealistic time frame. Under this pressure compromises enter the development process. Lack of time forces developers to resort to hard coding of values just to get the project off their backs. They develop a Let the next guy fix it attitude. Architectural designs that would save the company hours and lots of money over the long term are sacrificed in the name of haste.
Careless programmers have a tendency to just want to get a project completed. They would not care if the code is poor quality as long as it works for now. They are here to do a job and earn accolades and quick promotion and then would have moved to another company by the time the problem caused due to poor coding surfaces out – some other guy will fix it, is the attitude.
A careless approach to programming introduces bugs and overlooks several important data conditions, which in the long run make the software unusable.
Development teams are often stuck with the self-styled expert programmers who, after having been programming for a few years, tend to think that they are the experts and others are duds. They are unwilling to listen to the ideas of other team members. They are unwilling to learn the emerging technologies and techniques to enhance their wisdom. This fixed-headedness and the lack of willingness to learn and adopt newer methods is a sure shot peril for the programmer and the software project that he engages into.
One of the major deficiencies in IT departments and software companies is a lack of standards. Standardization ensures a more engineering approach to software development. Developing standards is a tough task and requires long term vision. It requires research into software technology and intense efforts from developers, architects, and managers to write a good set of standards for all to follow. It demands a willingness to not settle for the quick and easy solutions. Developing standards requires an investment in time, money and brain, which most organizations lack.
Developing Standards does not mean simply defining naming conventions and in-code documentation. There is much more to it. You standardize the entire technology platform on which all your developers will work and build the software. This should cover - a standard open systems reference model, a standard technology profile, a single operating environment, a standard for interface design, object oriented architecture, software partitioning, dependency analysis, and so on and so forth.
Once the standards are defined and well documented, additional effort is required to protect them and ensure that all developers adhere to them. Slothful developers, architects and managers will compromise and tend to deviate from the standards. Especially, when you hire self-styled experts who may not care to take out the time to understand the defined standards and will try to dictate their own practices and attempt to change your standards.
Greed creeps in when you want to milk your customers to the maximum. Deliberate attempts to make the software unnecessarily complicated and requiring frequent intervention by the programmers, has the underlying motive of keeping one's job secure and continuously milking the end users or customers. Developers resort to these practices with the motive to always keep the end user/customer dependent on them. Making things complicated ensures that they remain in demand even after the project is complete and are guaranteed of several man-hours of training, customization, and support.
Some managers have glorified this with the phrase - buyer lock-in. I personally feel that this is bad business practice. The golden rule is - never undermine the wisdom of your customer. Customers are smart enough to soon realize that they are being taken for a ride and once they do so, it is dooms day for the programmers and for your business.
An arrogant programmer often has a distorted view of reality. Instead of seeing himself as a helper of others, this person is at the center of his own universe. If such arrogance creeps in, a software project is doomed. It is almost impossible to establish a relationship or work with people driven by arrogance. They do not listen. They are not helpful, rather they are treacherous.
Any idea that did not come from the arrogant programmer is deemed to be a bad idea and is not given due consideration. Other team members would suffocate in the environment that arrogant programmers create. Creativity is lost, team members lose interest, and this eventually leads to failure of the project. There is no place for arrogance in the software business. It is a killer.
This is the worst of the lot and a trait found in many organizations. People are envious of each others success and tend to bring each other down. An envious programmer may resort to back-biting and would go all out to scuttle the efforts of other team members. These programmers jealously guard their own little treasures. This results in holding back information that could otherwise enhance a project. It is a time killer and reflects an unwillingness to be part of the team.
Where jealousy really starts to hurt is when others in the team become suspicious of another team member's motives and hatred creeps in. Team members will form their own smaller groups and start playing politics with the intention to undermine the work done by the others. Focus on the project is lost. Projects have been killed on account of nothing more than jealousy, envy and hatred.
As a leader of a software team, you need to be conscious of the above pitfalls and make all out efforts to overcome them and create a conducive environment for success of your software project. Team leaders who have accepted the above challenges and adopted methods and practices to tune team members to positivity have been successful in coming out with great applications.
CEO, Computer Solutions
Rajeev Kumar is the primary author of How2Lab. He is a B.Tech. from IIT Kanpur with several years of experience in IT education and Software development. He has taught a wide spectrum of people including fresh young talents, students of XLRI, industry professionals, and govt. officials.
Rajeev has founded Computer Solutions & WebServicesWorldwide.com, and has hands-on experience of building variety of web applications and portals, that include - SAAS based ERP & e-commerce systems, independent B2B, B2C, Matrimonial & Job portals, and many more.