Developing big applications requires huge effort. There may be teams for each phase of development and they must use different design patterns and go through the whole SDLC.

I have two years of experience as a software developer on small applications and I'm interested on what are the common approaches & practices for big applications? Especially from a project management perspective.

How can I adopt such working practices?

  • hey yannis thanks for editing but i think you can also give me a better answer – Sumit Neema Jan 23 '12 at 5:40

Working on large teams is definitely a new experience. You are no longer going to be able to understand or probably even have access to the entire code base that makes up your product. You will likely have to go through peculiar process controls that don't really relate to what your team is doing or how they do it, etc.

I am still getting a grasp on this subject myself but I think my key take away so far is:

  1. Specialize in your area

    You don't need to understand the entire eco-system, and trying to do so can actually hinder you especially when initially ramping up. When starting out I would recommend focusing on understanding just your code and the logical boundaries off how your code interact with other teams code (Shared Databases, Caches, SOAP/REST Services, File systems, etc.) and whom your up and downstream dependencies and dependents are.

  2. Become an expert at finding the expert.

    In large organizations there are simply too many moving cogs for any one person to have intimate knowledge about the internal workings of each discrete system. Becoming really good at figuring out how to find the one person or wiki page that does have the answers you need to solve your own product or process issues is really a skill set you will want to pick up.

    This means knowing a little bit about your organization's structure, and who to ask questions about to get information on a specific subject or who to ask questions on whom to ask questions on who to ask questions on a particular subject.

    Knowing and being on good terms with your software architects, project managers, leads developers etc. all comes in very handy here.

  3. Relax. Organizing large software projects is hard. It's a thing. The expectations on how you go about doing things and getting answers is different. The skillsets are a little bit different from the ones you use on smaller teams but you're a go-getter and just like everyone else when they made the jump to large teams you'll get the knack for it. ^_^

As far as design patterns and the technical stuff.

I don't think there are many major changes on the design patterns used on small projects versus large projects. A factory is a factory is a factory right?

At the same time to deal with the large number of people involved there tends to be push to compartmentalize specific components of the application so that they are as independent and decoupled from other components as possible. In my current role I see a lot of N-Tier diagrams with plenty of little boxes denoting specific product functionality. for the most part each team is responsible for one or more of those specific boxes. So we get very precise about what our components ins/outs are and requirements since we cant just change those details willy nilly due to the layers of people involved in making changes.

My division doesn't take this to the extreme that some other businesses do but if you are working on a large distributed solution rather than a single large program like say Ubuntu or Windows you might be digging into a Service Oriented Architecture such as the model Amazon has going on in order to facilitate this separation of concerns.

Much like the n-tier architecture diagrams with specific logical components, SOA is very handy in that if you do things in the correct manner and implement solid interface version control mechanisms and communicate upcoming interface changes upfront you can enable multiple teams to work on VNext solutions in parallel by working against stubbed endpoints and predetermined interfaces until some point down streams when the various services are functional enough to begin connecting to directly to one another to begin serving actual responses rather than canned stub/mock responses.

There are also some very interesting processes around development environment setup when working on services with interdependencies between services that are all being developed in parallel, and how you can insure each teams' or the shared companies' development environment has the latest bits possible deployed without introducing major functional breaks that block other teams.

|improve this answer|||||
  • 1
    +1 @Keith Brings: Good answer, though believe you've misunderstood user972809 question, which is "I want to know as a developer with two year experience, who develops only small applications, how can I adopt more professional practices of big companies and great developers?" Basically, it is way to open ended of a question in my opinion -- and easy to see though, how you came up with the answer you did given the posters broken English. Again, just my reading of the posters broken English, but do believe that's what they meant. – blunders Jan 21 '12 at 8:42
  • Thanks Blunders. Noticed that after re-reading the question a bit. Adding some details on compartmentalizing software on the comment below ^_^. Big software is a big subject! Grr perhaps still answering a different question. I think the original poster is interested in application lifecycle management . . . and best practices. If that is the question: BDD, TDD, Write out some brief specs or user stories before you start coding, sketch out your design on a white board or piece of paper before you start coding. Read the Gang of 4 books (Design Pattenrs) a few times. – Keith Brings Jan 21 '12 at 8:44
  • Yeah, I tend to view these questions as okay, but pretty sure it'll get closed. Reason I feel their okay is because my guess is a new user that get told you don't understand and respect our complex system, is just likely to leave and never come back. And who's going to post answers to questions they know are going to be closed/delete... :-) ...again, great answer, just don't believe it addresses the question, which is a question that really does not have an answer of value in my opinion. Cheers, and glad to hear my feedback was of use! – blunders Jan 21 '12 at 8:50
  • 2
    Honestly my response would be write more code, join a large open source project. There's a million best practices, but real learning comes from doing in my opinion. By writing code, that's used, gets complexity, etc - people naturally evolve to solve those problems; or at least I would hope... :-) – blunders Jan 21 '12 at 8:54
  • 2
    The more we know, the more we know we don't know. – Keith Brings Jan 21 '12 at 9:11

You asked "... how to adopt to such working practice ...". I don't think there's any real shortcut answer. If you want to learn how development happens in a large company, go and work at a large company, and see what they do (and how well it works). After a few years, go and work at a different large company, see what's different and what's the same. Repeat this a number of times.

I've been in IT for around 20 years, and I'm still learning how development happens. I've worked at a large number of companies, both big and small. They're all different. They all do some things well and others poorly. But I've learnt something new about software development at every single one of them.

Sorry, but there's really no way to get experience, other than by getting experience.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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