Make Mine Large
The wash from a large project can drown reputations and careers. Have you got the courage to swim with the big fish?
by William Knight
“Dream big, work hard, and good things will happen,” the saying goes, but it seems that for software projects big dreams often turn to nightmares. Despite today’s catchphrase of small dreams more often, sometimes businesses have no choice but to build huge project teams that create a wake like a supertanker in a gully. It’s easy to get washed up in the surf.
Working on a large project is like nothing you’ve ever known. If you have been used to small productive teams, then moving to a 50-person project would present a terrible shock. At its worst, individual productivity disappears resulting in frustration. Requirements are cancelled, other¡ªseemingly irrelevant¡ªrequirements are added, and the project whirs around without anything being achieved. Even optimistic planning utilizes each developer for just three days a week with the other two days consumed by who-knows-what administration, meetings, holidays, and joining and leaving celebrations.
Julien Thomas, solutions architect leader for a banking services company and veteran of many multiyear projects said, “There seems no light at the end of the tunnel. You don’t know most of the people, and they join and leave the project on regular occasions.”
In this situation it’s easy to become demoralized. The fabulous code you designed is lost in reviews, arguments, and trials, and finally ignored because management focus has moved to the next crisis.
Management based on a matrix is commonly employed with horizontal concerns taking precedent over technical issues. Your design for the user interface was perfect, but the Human Factors manager has other ideas. She’s not part of your team and has waited until the end of coding to tell you to read Standard XYZ and do it again.
Management from the sidelines is an obvious problem of big projects, but there are subtler, more damaging consequences of management hierarchy. Conway’s law states that design follows the organization structure. So whatever the hierarchy of the project looks like, there will be analogous design artifacts, which can mean the nontechnical project director is responsible for architecture. Once the organization has been established, desks laid out, and department leads assigned, the design is mostly decided.
It is common to lament missed design opportunities, but decisions are out of the hands of technicians and change means wielding power in the business environment. If you have a great idea for a common process used across the project, then be prepared for limited take up. While you’re waiting for agreement in endless meetings, the Web boys have already started putting business code in the server pages and circumventing the ideas you are trying to get passed.
Thomas added,”There are usually a number of project managers running subprojects and doing it in their own style. You talk [to a colleague] on another subproject, and he may as well be on a different project¡ªthere is nothing in common in what you are doing. You think you are building a ship, but he’s building a skyscraper.”
What Is Large Anyway?
The difficulties in running large projects have led to a number of proposed solutions. It is often said that team sizes of less than ten are optimum, and work should be split into subprojects to achieve it. This solution can cause problems as a result of Conway’s law if not done carefully because cross-project issues can be forgotten when there is no clear ownership.
The open source community is now responsible for some of the largest software projects of them all. David A. Wheeler, author and software developer said, “At one time it was commonly accepted wisdom that open source/free software approaches couldn’t build large systems.”
But this judgment has been proven wrong as Wheeler added, “Debian 2.2 was found to be 55 million physical SLOC [source lines of code], and would have cost nearly $1.9 billion [U.S.] using over 14,000 person years to develop using traditional proprietary techniques. And Debian 2.2 is old too; current Debian is bigger still.”
The approach to development has made open source a success, but for many enterprises collaborative development of the open source variety is not an option, and more traditional processes must be followed.
Staff are formed into fixed, function-led teams and given responsibility in perpetuity for lumps of code, and this process can toll the death knell for your career. Without careful management of your personal development and being prepared to change jobs once in a while, it is easy to be turned into the indispensable project guru for a narrowly defined area of the project. It may be fine for the wallet, but it leaves you exposed should anything happen to the company or you want to move on.
Tony Butterfield, CTO and founder of 1060 Research, said of working on a large project, “It’s good if you just want to get paid and have security for a long time; bad if you care about what you are doing and want to see results and take pride in your work.” For this reason, after years of working as a contract developer, Butterfield started up his own development house.
And that seems to be a way out for many developers¡ªa change in direction. On a large project the money is often good but the work becomes tired. It is easy to become entrenched in a minor facet of technology or perhaps become so high level that your development skills wither. Many developers prefer to code fast and loose; it’s more fun and harks back to a creative spirit that many large projects lose.
Surviving Large Projects
There are strategies, however, for surviving the large project. Here are some points to consider if you wish to have a healthy life:
1. Keep your eye on technology developments outside of the project, and don’t get bogged down in one area unless you absolutely love it.
2. Remember that all the developers are in the same position. Try to remain team focused¡ªthe project’s goals are your goals.
3. Don’t take arguments personally, and don’t get riled when decisions go against you. Live with team decisions, and try not to revisit them.
4. Make sure you put your views across, and take part in discussions; otherwise, you will feel alienated. But don’t forget point 3.
5. Avoid arguments of a faith-based nature. You may not have written the coding standard, but criticizing it continually will only result in bad feeling. Drop, once and for all, your determination to have in-line bracing.
6. Work with what you have. Be creative within the existing structure, and try not to change the world. Set small targets for change: “evolution not revolution.”
7. Don’t be upset by code reviews, and don’t avoid inspections of your work. Be proud, use your work to instruct others, and try to learn from other people’s ideas.
The challenges faced by large projects are complicated, but some people wouldn’t have it any other way. For me, the challenge of convincing a large team to take up a concept is part of the enjoyment, and the discipline required hones the mind and necessitates careful research and formulation.
Working with dozens of colleagues on the same project for years is not everyone’s cup of tea; it requires diplomacy, tenacity, and, not least, a sense of humor. But it is our ability to organize ourselves and overcome difficulties together that makes us so wonderfully human.
About the Author
William Knight develops software and writes about the process. In a career of 20 years spanning structured programming to MDA, he has seen the industry both fulfill and fall short of its potential to serve.