My top ten list on how to succeed with large projects. (1)

Do not forget the customer

Customers pay for your fun job, they know the problem area much better than you do and they share an interest with you to make a good program. Do not forget them!

In an ideal world customers should be as entwined in the project as the developers, project managers, architects... For some reason there is usually a need to fight with them a bit to make them a part of the project. Try telling them that the project costs so many millions and that without the know how for a comparatively small cost the project might fail. 

The project needs the customer. Their involvement brings so many vital benefits and very few hazards. You minimize the risk that you will discover that you misunderstood what the system was supposed to do after a few months, you solve problem areas much quicker and you have nicer coffee breaks. 

The customer on the other hand will hopefully start to understand the fabric of your work and he will be reassured to see that you are not only taking coffee breaks all of the time. At least not without him.

My top ten list on how to succeed with large projects. (2)

Keep expectations where they should be

There are many pitfalls when time estimating or promising features. You may be overly enthusiastic and get swept away by the enthusiasm, you may believe too much in your own abilities, you are afraid to tell the customer the real costs, you simplify the impact of the uncertainties and risks in the project or you simply forget about all the boring stuff that needs to find time as well such as testing, documentation, meetings...

There is a saying that you should multiply your estimates with pi, but I don't buy that. Better to learn how to estimate correctly and to know when not to estimate than to just tell the customer that the project will cost three times as much as you believe. In the end no one will be happy if the project gets delayed.

Honesty is a good trait. If you cant make an estimate say so. And try to keep your hybris and megalomania pinned down, so common traits among developers. After all we are a bit like gods, being able to create anything we can imagine in the virtual world called a computer.

My top ten list on how to succeed with large projects. (3)

Industrialize!

Sometimes it seems like it's rude not to include everyone in all parts of the project resulting in a development method where every developer is part of the process from GUI down to the database and the external services. 

Software development is at the same level as how cars were produced before the T-Ford. They are built by hand, painstakingly, and they still end up with quality flaws that would have been corrected with a more industrial approach.

Software development methods are of course getting better, but still membership in a project is something that puts developers in a position where they are supposed to work eight hours a day from the start until the end of the project. It matters less if they are the best for the current task or not, yet in a project there are some highly specialized tasks that needs specialized skills like usability design, deployment, graphic design, performance testing etc.
How many of you haven't seen a good developer spending weeks on making lousy graphic design, buttons and the like? (For some reason few people seem to have strong skills in design and programming at the same time)

On the other end of the spectra we have projects where you appoint a manager or an architect even though you know that his or hers commitment is limited in time or effort. Putting an architect for the first months only in a big project will only damage it. Leading roles in a project should be long term.

So how do we get to a point where we can industrialize the process of making software?

I think that one important step is to sell more solutions than resources to the customer. If you sell a consultant for six months to a customer, he will stay there. If you sell a solution that will take six months to complete you will have a freedom in the staffing and you have at least a possibility to put the right person at the right task. Another important step is to have simple rules of thumb on staffing a project always striving to put the right person on the right spot with the right level of commitment.

My top ten list on how to succeed with large projects. (4)

Responsibility makes better software

Last entry on this list concerned losing control over the project, this one shares the subject. Having control is a key to not only manage and finish a high quality project in time, it is also vital for the developers ability to sleep at night. 

So who's fault is it if something goes wrong? If the database ends up without normalization and the business layer turns up as a huge mass of code with ugly dependencies in every direction. 

In many projects that is a question that no one can answer. "It just grew out to be like this" or "we had so little time" are common and sometimes valid excuses.

I believe in responsibility. I believe that someone should be responsible for the structure in the database, in the business layer, the unit testing and that everyone follows the GUI guidelines of the project.

The reason for this is not because I like to punish people, the reason is that issues have a tendency to fall between people, to disappear and gather dust. This can to some extent be removed with clear responsibilities. If this is my area I want it to be as good as possible, that would at least be my instinct.

I wouldn't want to be caught up with tables without primary keys in my database and I sure as hell would want my business entity to be as easy to manage as possible, something that is best achieved by doing it right.

Responsibility makes better software.

My top ten list on how to succeed with large projects. (5)

If you lose the map you're lost

Have you ever been in a project where the developers lost the big picture? It is tough to get back from.

If the map, the architectural blueprints, are lost it is like a disease out of control. The quality goes quickly from so-so to non-existing. People begin to duplicate code instead of using existing mechanisms, they put methods in other classes than they logically belong to and the cohesion gets more and more strongly coupled when the developers skip the architecture and shoots from the hip. And with bad code, unhappy coders.

The software architecture is more than just how the system was envisioned once in the beginning of the project. 

It is a guideline that should be kept alive throughout the project. It is the language of the project.

The architecture should continually be communicated throughout the project. A social gathering just as important as the scrum meetings or the project meetings. Focus on what should be where and how to reuse existing code. Focus on black box issues, code discussions beyond the classes and their interfaces are less helpful. As a developer I don't really care how a method is constructed as long as it accepts the arguments I want to change and do what I want it to do. Don't get stuck in details. I have seen too many projects where the  discussions is more about using tabs or spaces for indenting than entities. 

So to summarize: I propose an overview of the architecture every monday morning at 09:00! Keep the map alive!

My top ten list on how to succeed with large projects. (6)

Demand a TCO for system architectures.

Do you remember TCO? It stands for Total Cost of Ownership and was common in the nineties for corporation calculating the total cost of their computer and software investments. The calculus should not only include the initial cost of stuff, but also costs for management, licences, infrastructure, education, salaries etc. 

I believe it is time to take this paradigm to system architectures.

Architects and developers are usually geeks with an interest in their job. They like programming. 

And they also like everything that is new and hot and they are very curious about trying stuff. 

Stuff that stays interesting for a month or so until the next new cool stuff shows up.

Stuff that ends up deep in the architecture of the systems they create. 

Stuff that in the end can cost the customer a lot of money and what is bad for the customer is bad for the developers. (even if it can give them a longer project in the short term)

I don't mean that you never should adapt new programming paradigms, add third party libraries or use new patterns to build the software. System development is about evolution, otherwise we might all just stay programming COBOL.

I do however mean that you should think before you do it.

Think in terms of "How much do I gain by using this new stuff?", "How much will it cost?", "How much more complex will the code get?", "Can we find developers that know this stuff or will people make shortcuts and further degrade the architecture?", "Will this new stuff be legacy in a few years or will it stay?". "Do we really, really need this?", "Which are the alternatives?"

In short make a quick TCO-analysis. Don't just buy the buzz words without thinking.

My top ten list on how to succeed with large projects. (7)

#7 Scrum slowly in the beginning.

I really like scrum or other agile methods, but I am not one of the religious fanatics. Scrum like any method has its strengths and weaknesses. Scrum is time boxed and is focused on dividing a task into smaller subtasks that can be given time estimates. It is an effective method when the domain is well known. The focus on what instead of how can however be a problem when making the system analysis. It is all too easy to forget that you cannot build a system without taking time to make up a lasting architecture, simple enough to be understood and rich enough to cater for the whole system, not just for a sprint. Although agile methods have mechanisms for system analysis, it just doesn't seem like a first citizen. Agile methods are focusing on keeping the work and produced code up, not for taking it slow and think. But no thinking makes a stupid system architecture.
Don't do until you know what to.

System architectural decisions early in a projects lifetime are decisions that lives for a long time and are hard to change. It can be mistakes that will cost many, many hours.

So use scrum, but take it slow in the beginning. Make time for some thinking.

My top ten list on how to succeed with large projects. (8)

#8 Cut up the cake

Have you also been in a project where you afterwards said stuff like "yeah, we should have done it in smaller pieces" or "I don't understand the system anymore"?

Software systems are like tigers, they start all cuddly and sweet but suddenly you have a 1000 pound man-eater in your office. And once you lose control over the beast it takes lots of effort to regain it.

The bigger the system the harder to control, but somehow, even though we all know about the importance of using modules when coding, it is easy that the system gets to big to understand.

Modularized code is almost as old as programming itself, but to use it you need to think before you start coding and you need to continue thinking while you add new functionality. 

Common sense, right?

My top ten list on how to succeed with large projects. (9)

#9 Isolate

For me succeeding with a project is to reach high quality and stay within budget. To be able to take responsibility for any time schedules and to be able to reasonably well give a good guesstimate on how long  time a project will take you need to know what you are calculating on.

You can never calculate time for external projects. Still most software systems don't live on their own, they have dependencies to external systems, systems that can be unstable, changing or not even constructed yet.

It is a problem. A problem that can be yours if you don't handle it.

If you isolate your software and never make demands of any other functionality than that contained in your system it shouldn't be a problem. But in real life system borders can be unclear and vague and if you don't code for isolation it can be hopeless to see where a problem spurs from.

Some tips:

• Keep your own data carriers. Loosely coupled code are tenfold more important when working with external components.
• Build for robustness. Treat all external services as unreliable and always code with that in mind.
• External frameworks and components can be nice, but they also makes your system more depending on external systems. Think twice.

My top ten list on how to succeed with large project (10)s.

#10 Treat the requirement document as an evidence in an upcoming murder trial. With you as accused.

Sellers are sellers and they will always be sellers. Their job is to land deals, sell in stuff and in many cases get a fat provision for doing so. There is a small gap between selling and delivering a solution.

That responsibility lays on the project manager and below him, the system architect and the developers. To add to the problem more and more projects sells for a fixed or semifixed price, risking to give the development crew an impossible task at an impossible price.

What will be constructed is specified in the requirement document. If you want a cv that will not scare away your future employers (because the risk is that you will get sacked when a fixed price project takes a year too long at a cost of x millions) you need to treat this document with utmost respect, because if shit hits the fan this document may prove to be your executioner or your saviour. 

Fuzzy requirements will be the foundation for a fuzzy system and I am not talking fuzzy logic here. Responsibility is a dangerous beast, best treated with respect.

When the project lands on your lap after the seller sugarcoated it, it is up to you to make sure that no work is started without clear requirements. The first job in a project with fuzzy requirements should be to sharpen the specifications, no matter if it is done with analysis, prototyping or with customer workshops. Fixed prices should not be negotiated until customer and consultant agrees in a sufficient detailed way what is going to be built. 

The same rules applies when building the system, beware of gliding requirements or demands that are not specified in the requirement document. You are promising to fulfill whats in this document and you are obliged to make the customer take the consequences as soon as he wants functionality that's not included in this document. 

Of course it goes without saying that accepting a requirement document when you know it lacks vital functionality that the customer will have to pay for later is both unprofessional and unethical. 

You will not keep customers by backstabbing them.

Common sense. Only do when you know what to. 

Wonder why common sense is such a rare commodity. Maybe it has something to do with money.