7

The situation

Let's imagine a couple of developers start LittleProject™ inside of a company. No Unit Testing, no Jenkins, no Docker, a single development environment... "why would you want more? It would be overkill."

The project is successful and grows bigger and bigger. More developers are added. A couple of testers are hired. Then, after a few months, the group has grown to around 20 people, and the manager starts to realize that LITTLEProject's™ growth has slowed down to a crawl because of the development process the team is using is obsolete or inadequate for this scale, like hiting a "methodologic roof".

The question

LITTLEProject™ is not little anymore, and no longer can advance at a steady pace unless you improvethe the development process used. Is there a name for this effect?

Complete this sentence: "Our development is stagnant until we change our development process. (We are/Our project) is/has __________"


Clarifications:

About what I mean by "development process":

The problem LittleProject is facing is NOT related to things like "we are using X technology (PHP vs NodeJS, or MySQL vs NoSQL, for instance) and it doesn't scale well". I'm talking about missing, misusing or choosing the wrong methodology and practices, which may include things like:

  • using bug tracker
  • using VCS
  • manual SASS compilation versus automation
  • defining a common coding style guideline (no matter which one)
  • unit testing
  • regular meetings
  • etc... ((This is not a list of the things LittleProject™ is missing, just an example of the kind of things as opposed to technologies (mentioned above) like programming languages, target operating system or database managers ))

About what I am exactly asking for:

This question is, essentially, a word-request question. I'm not looking for an analysis of the situation or advice to solve it, just a name for it.

closed as primarily opinion-based by gnat, Robert Harvey, Greg Burghardt, Bart van Ingen Schenau, Doc Brown Jun 21 '17 at 15:44

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 9
    Sounds like technical debt; you made engineering decisions that are now limiting you. – jonrsharpe Jun 20 '17 at 16:29
  • 20
    Any project of any significance with more than 0 developers should be in version control. – JAB Jun 20 '17 at 18:59
  • 2
    An old boss of mine called this "incompetence". – T. Sar Jun 21 '17 at 10:57
  • 3
    no project is too small for VCS – jk. Jun 21 '17 at 12:19
  • 2
    Complete this sentence: "Our development is stagnant until we change our development process. (We are/Our project) is/has __________" --- "stalled," "gone off the deep end," "jumped the shark," "ground to a screeching halt." Not really sure why you're looking for a term here... Instead of looking for a word or phrase, perhaps you should shift your focus to how you are going to fix it. – Robert Harvey Jun 21 '17 at 16:38
6

You're still talking about ability to scale. You're just talking a development methodology that isn't able to scale.

There is a unit that some management types like to throw around called a man-hour. Let's say project x took 500 man-hours. A number that could be the product of either 5 people working 100 hours or 100 people working 5 hours. As if those two situations produce the same amount of work simply because they equate to the same amount of cost.

That kind of thinking is what leads to the expectation that a late project can be put back on schedule by adding people. It isn't true. Work and cost are not always 1 to 1. This change creates problems that hurt productivity so there is a false equivalency here. Failing to expect this result is man-hour thinking.

The famous Mythical Man-Month book takes it's name from this unit talks about this effect. Adding people late to a project slows it down. The reasons it gives ranges from inter team communication growing by n(n+1)/2 to developers trying to come up to speed eating the time of experienced developers who now have to hand hold people that risk breaking the build.

The Agile world believes that teams should shrink not grow. New people need a safe place to learn what they're doing before the they contribute. They need access to experienced developers but that comes at a cost. If you're not willing to pay it let the two developers that started this get back to work and have everyone else start some other project.

Now if you've taken all that into account and still think you're being slowed down by something more than that it could be your first two developers are solo heroes.

Working on a project alone simplifies a great many things. If something is locked you locked it. No one steps on your work except you. It is a special kind of awesome. However, it means you are alone. Every dumb idea you have sees the light of day because no one questioned it. Every blind spot you have is unguarded.

And it means you don't learn to work with anyone else. You started with two who figured out how to work together. But working with a team of 20 people is very different. Planing, dividing up work, testing, peer reviewing, source control, integrating, deploying all require much more discipline in a team of 20 than in a team of 2.

And in fact a team of 20 is flat out ridiculous. The pizza rule says if it takes more than two pizzas to feed your team it's to big. My rule of thumb is if talking to your whole team feels like public speaking it's to big.

18 people should not have simply been "added to the team". Ideally you never grow a team. You let it shrink over time. So where do you go if you've already started with 2?

  • Split up the two experienced developers. This lets them go on to lead two different teams. All they need is two different areas to focus on. Ideally you only add 1 or 2 more developers for these experienced developers to train up.

  • Start a separate team. This teams work should be separate enough that they don't have to meet with the experienced developers constantly.

A good size for a team is 4 to 8. Ideally this will let them co-locate so that they can turn around in their chair and talk to their entire team without people having to get out of their chairs to see each others faces.

Sometimes a team just has to grow. When that happens it's much less of a slowdown if the number of new people on the team is less than the number of experienced people.

  • Very good points about team growth. The “Peopleware” book by DeMarco & Lister also discusses “teams” extensively, and notes that you can't really grow a team: every time someone is added or leaves, you get a new team that will take some time to get to know each other and find a way to collaborate effectively. I'd highly recommend this book for anyone interested in the social aspects of corporate software development, even though it is mostly an opinion piece and not factual research. – amon Jun 20 '17 at 19:51
  • 1
    I'm torn. This answer has very valuable and insightful information and advice, but only the first sentence answer my question. The rest is (somehow) unrelated to the question. – xDaizu Jun 21 '17 at 10:23
  • @xDaizu note edit – candied_orange Jun 21 '17 at 10:49
  • @CandiedOrange I did. There is still a lot of paragraphs dealing with how and why we got to that (hypothetical) situation and how to solve it. That information is of no use in the scope of this question (but it would be a good answer to a potential future "How do I approach solving (this situation)?" separate question :) – xDaizu Jun 21 '17 at 11:24
  • The phrase "ability to scale" bothers me in this context. Despite Wikipedia's assertion that the word "scale" can mean many things, I still consider its primary definition as "the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged to accommodate that growth," and consider other uses (like Which programming language scales the best?) to be abusing the term. See also MongoDB is Web Scale. – Robert Harvey Jun 21 '17 at 16:46
4

The IEEE came up with a "Capability Maturity Model for Software" many years ago, often referred to as CMM. While the standard is pretty old, it's still a decent framework for understanding why your team seems so dysfunctional.

CMM makes note of five levels of capability maturity:

Level 1. Ad hoc

At the Initial Level, the organization typically does not provide a stable environment for developing and maintaining software. Such organizations frequently have difficulty making commitments that the staff can meet with an orderly engineering process, resulting in a series of crises. During a crisis, projects typically abandon planned procedures and revert to coding and testing. Success depends entirely on having an exceptional manager and a seasoned and effective software team. Occasionally, capable and forceful software managers can withstand the pressures to take shortcuts in the software process; but when they leave the project, their stabilizing influence leaves with them.

Level 2. Repeatable

At the Repeatable Level, policies for managing a software project and procedures to implement those policies are established. Planning and managing new projects is based on experience with similar projects. Process capability is enhanced by establishing basic process management discipline on a project by project basis. An effective process can be characterized as one which is practiced, documented, enforced, trained, measured, and able to improve.

Level 3. Defined

At the Defined Level, the standard process for developing and maintaining software across the organization is documented, including both software engineering and management processes, and these processes are integrated into a coherent whole. This standard process is referred to throughout the CMM as the organization's standard software process. Processes established at Level 3 are used (and changed, as appropriate) to help the software managers and technical staff perform more effectively. The organization exploits effective software engineering practices when standardizing its software processes. There is a group that is responsible for the organization's software process activities, e.g., a software engineering process group, or SEPG [Fowler90]. An organization-wide training program is implemented to ensure that the staff and managers have the knowledge and skills required to fulfill their assigned roles.

Level 4. Managed

At the Managed Level, the organization sets quantitative quality goals for both software products and processes. Productivity and quality are measured for important software process activities across all projects as part of an organizational measurement program. An organization-wide software process database is used to collect and analyze the data available from the projects' defined software processes. Software processes are instrumented with well-defined and consistent measurements at Level 4. These measurements establish the quantitative foundation for evaluating the projects' software processes and products.

Level 5. Optimizing

At the Optimizing Level, the entire organization is focused on continuous process improvement. The organization has the means to identify weaknesses and strengthen the process proactively, with the goal of preventing the occurrence of defects. Data on the effectiveness of the software process is used to perform cost benefit analyses of new technologies and proposed changes to the organization's software process. Innovations that exploit the best software engineering practices are identified and transferred throughout the organization.

Without automated build tools and the like, it seems doubtful to me whether your organization could even reach level 2. So if you are looking for a term, you could say that your team is mired in CMM Level One.

  • 2
    Dear god... my previous company was somehow simultaneously both lv 1 &5... – RubberDuck Jun 20 '17 at 21:43
  • 1
    This is the kind of answer I'm looking for, thank you. It answer my question "How is this situation called/classified?" instead of trying to give advice about how to solve the situation. :) – xDaizu Jun 21 '17 at 10:19
  • Interesting, but I very much disagree that automated build tools are essential at any of these levels. They're a byproduct of having a complicated build process, which ironically happens pretty quickly when you decide to use a lot of other tools. Adding tools to the process has much less to do with whether the team is repeatably succeeding, or whether the organization has processes in place or is in optimization mode. – svidgen Jun 21 '17 at 14:15
  • Or for a more simple version go look at the "Joel Test" just swap out the nightly builds for a CI System – Zachary K Jun 22 '17 at 7:35
2

If I were being harsh, I'd call a situation like this where progress is now being blocked by a long-term decline in productivity "bad management". The primary job of the manager is to make sure impediments to progress are removed, and it doesn't sound like this has happened.

What you actually call it doesn't really matter - the team needs to invest time to get the development process working again, and that's going to cost the company money.

  • 1
    I agree with you, but I'm charged with making a report of the situation to show to the higher-ups and you know how much they like them "fancy words", related articles or even academic papers. Getting a name is the beginning (also, my own curiosity) :) – xDaizu Jun 20 '17 at 16:32
  • Personally, I disagree that senior management want "them fancy words". What they want, in order of importance is: 1) how much will this problem cost to fix? 2) what's changed so that it won't happen again? 3) what actually went wrong? And "there wasn't time, we had to code features" is bad management if it leads to problems like this - strong management would be aware of the upcoming problem and push back. – Philip Kendall Jun 20 '17 at 19:11
  • 4
    "there wasn't time, we had to code features" is NOT bad management if getting the product out the door fast was a priority. Shipping Fast is a feature, do not blindly assume that incorrect decisions were made in the past just because you've run into technical debt now. – Graham Jun 20 '17 at 19:31
  • 1
    Senior management should have been made aware of the technical debt that was being built up. If they were, why is there suddenly a need to explain to them what's happened? – Philip Kendall Jun 20 '17 at 20:15
  • @PhilipKendall Sorry, but none of the 3 questions your wrote in your comment are really relevant to the scope of the question. Maybe the question is poorly phrased (I accept edit suggestions), but I only want to know the name and/or classification of the (consider hypothetical) situation, now how we got there or where do we go now. – xDaizu Jun 21 '17 at 10:27

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