Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

A person new to programming may be able to make a good small program.

However, when starting to work on anything bigger than a small (think 1 C source file or Python module) program, there are some general concepts which become much more important when working on "big" (think many Python modules or C files) programs; one example is modularity, another is having a set aim.

Some of these may be obvious to people who went to school to learn programming; however, people like me who did not go to programming classes sometimes have to learn these things from experience, possibly creating failed projects in the meantime.


Please explain what the concept is, and why the concept becomes more important for big programs than by small programs.

Please give only 1 concept per answer.

share|improve this question

closed as not constructive by gnat, Jarrod Roberson, Thomas Owens Jul 6 '12 at 16:41

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Can someone who is able to, make this question a community wiki? –  Abbafei Mar 23 '11 at 22:29
You can do it yourself by editing and clicking the "community wiki" box. –  orlp Mar 23 '11 at 22:36
@nightcracker : it is not coming up for me when I edit. Maybe I have too low reputation for making questions wikis? –  Abbafei Mar 24 '11 at 1:32
@nightcracker and Abafei: It's been disabled for users, but mods can still do it. (A post on Meta.Programmers linked to that one) –  Izkata Jul 5 '12 at 21:25
I think leaving this question open for polling answers ( one concept per answer ) request is sending a mixed message to newcomers and confusing to what is constructive and not constructive and what is a real question and what is not a real question. –  Jarrod Roberson Jul 6 '12 at 15:19

12 Answers 12

System Integration

In large projects, you will face some old systems which will have been working for decades. In such systems, you will develop portions of code individually and then putting them into the system. This is called System integration (Joining new system with the old systems together).

You can take a look at these links:

share|improve this answer


It's is of paramount importance to understand how encapsulation facilitates change by means of keeping implementation details hidden from the client of a given API. It's also important that developers take the responsibility of designing the public API of their reusable components very seriously in order to enforce encapsulation, facilitate change and foster modularity.

share|improve this answer

Team Communication

It's not exactly a programming concept in itself, but it definitely is one that you need to embrace. Programming is a social activity, once you get out of your garade or dorm-room. Even if you do remote-work, and work mostly isolated, it requires constant communication with your team-members and stakeholders.

Something that, unfortunately, is far too often neglected by developers.

share|improve this answer

Software Development Life Cycle

You may not need to pay much attention to it for medium-size projects, but large ones will definitely require a minimum of structure and organization.

The SDLC describes the permanent refinement of your development process and all the tasks that partake to it, from inception to delivery (and even support, if you wish to extend it this far).

Software Development Life Cycle

Recommended Reading:

share|improve this answer

Continuous Delivery

Large projects need to be tracked and built regularly, with the finest level of granularity possible. Preferably, set up a Continuous Integration and Continuous Inspection system to produce a Continuous Delivery pipeline, allowing you to tag valid builds and promote them easily into milestone, beta, RC or release builds.

Continus Delivery Pipeline

Integrate with other tools to taste (for instance, linking to issues, source control repository web-views, code review managers, etc...), and let your developers focus on their work while your CD infrastructure supports them by giving them timely feedback on their progress.

Recommended Reading:

share|improve this answer


Always prototype bits and pieces of application functionality before going full force ahead. It's very hard to know ahead of time how different pieces of a project will fit together and how the global application state will be spread throughout the code base. Often times there are several good places a piece of functionality could go and you won't know ahead of time if you've made the right decision until there is some working code in place.

share|improve this answer

Automated Testing

With a small program, you can easily keep it in your head, and one person can do all the work needed. But ones you have multiple people or enough complexity that you have to think hard, you want automated tests.

Sure, you can test thing manually. And sure, if you think very hard about every change, you can get by for a while. But manual testing is a waste of valuable programmer time, and there are better things to think hard about than whether you've broken something. E.g., the broader design of the system, or what would make the app even more awesome.

share|improve this answer


Modularity means making a program out of small, reusable units (as opposed to a big mess :) ).

It becomes important when making big programs because:

  • It clearly separates parts of the program which do specific jobs
  • It can save much work when doing something similar to an existing thing
  • It is easier to understand how different parts of the big program work together, since it separates the functionality from the thing which uses it

Note: It can even be useful when working on small programs :-).

share|improve this answer
I think Modularity can also be known as "DRY" "Don't Repeat Yourself." –  The Muffin Man Mar 23 '11 at 23:45
Isn't it more "abstraction" than modularity? Abstraction is more general and apply on different levels in different forms, but it's all abou modularity in the end. –  Klaim May 20 '12 at 15:29
Modularity and DRY are different. You can write a 5000 line program that is one straight pass through - no modules, classes or methods, yet not repeat anything. Modularity means that you break up the code into distinct chucks each of which tries to do only one thing or a few things then you glue all the modules together. You can do this (use modules) but still repeat yourself if you wish so I really think of the concepts as different. –  Michael Durrant Jun 24 '13 at 18:21


The fundamental challenge of large software projects is managing complexity. Reducing compexity should be the major factor in every design decision. Write similar functions using similar code. Use self describing names. Avoid obscure language features.

share|improve this answer

Layered Design

The idea is that you decompose the system as a set of "layers", where each layer communicates only with the layer immediately above and the layer immediately below. This allows you to replace any layer(s) with debug layers, and wring out problems offline. This also allows you to isolate weirdness to one layer and a small number of routines.

See The Structure of the T.H.E. Multiprogramming System, by Edsger W. Dijkstra, for more information.

share|improve this answer


Sure, the application works fine on your desktop. And on your QA server (you do have a QA server, don't you?). And in production . . . with a few users.

And with a few more users.

And a few more . . . wait, it's getting sluggish . . .

Who posted us on Reddit?


share|improve this answer

Version Control

Such as git, svn, etc... Everyone on the team should understand how to check in, check out, diff changes, merge and revert bad code. It takes away some of the pressure of screwing up knowing that you can back out your changes. On a large team it allows you to keep track of who changed a particular area. It's not as important on a small project, but is vital on a large one.

share|improve this answer
+1 proper version tracking should be one of the first things to learn before making a "real" project –  bunglestink Jul 5 '12 at 21:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.