1. clean_start ensures you are ready to start new work. It does:
1. ‘pull -r’ (which fails if you have uncommitted work)
2. a refresh of the local environment
3.  ‘git clean -i’ in case you have untracked files you’ve forgotten about
4. a full test run.
   
2. onboard is the script to run if you are a brand-new developer and you need to set up your development environment. It will deal with setting up the environment (installing dependencies and any virtual environment) and runs the tests.
3. run runs the application itself.
   I started adding run scripts when I started changing between ruby, python, java and other projects and got tired of having to remember which incantation started the servers.  This is a shortcut.
4. run_tests will run all of the tests – every kind.
5. run_integration_tests will run only the integration tests (I don’t always separate these).

Another useful trick is to add a precommit hook so that you cannot commit locally unless all the tests are running successfully.

It can be helpful to have an LLM/agent/AI write these scripts initially and keep them up to date. You can do just as good a job as they can, but it is a fairly simple task that most of them can handle well enough.

If you are working with development teams (and aren’t a developer or ex-developer) then this might be jarring, but it’s intended for good and not for offense.

[Step 1] —- [Step 2] — [Step 3] – [Release]    

[Queue 1][Step1] -> [Queue 2][Step2] -> [Queue 3][Step 3] -> [Queue 4][Release]

You may already know me.

I’m a long-time developer, agilist, XPer, CI/CD, teaming/ensemble, TDD, and general software delivery specialist.

I wrote the second chapter of Clean Code.  I am the originator and co-author of Agile in a Flash with Jeff Langr, and I wrote Use VIM Like a Pro.

I’m mentioned in the “acknowledgements” sections of many other books on Code Craft, Agility, Design Patterns, because I’ve been heavily involved in the tech community and have done reviews and edits of their pre-publication materials.

I worked with “Uncle Bob” Martin at Object Mentor (twice). With his company, I taught physicists at Stanford Linear Accelerator Center how to improve software design for high-energy physics. I worked with companies like Caterpillar, Xerox, and many others.

I worked with Ian Murdoch (who founded the Debian Project) in his company, Progeny Linux Systems. We created software to aid in the creation of custom commercial Linux distributions.

I built industrial balancing machines with ITW.

I have worked with Industrial Logic (Joshua Kerievsky’s company) in the USA for the past 14 years. We helped companies create their flagship product. We worked with companies in oncology, heavy manufacturing, agriculture, insurance, respiratory health, and others. I’ve designed and delivered training courses. I’ve helped transform legacy code. I’ve coached software development executives.

I’m known as “the agile otter” (a play on my connections with XP and agile practices, and a play on my last name).

I have taught modern software practices and code craft to thousands of people around the world, including the USA, Canada, India, China, Germany, Hungary, Poland, Norway, Australia, and other countries. I enjoy international travel and love serving software organizations, whether large or small. 

I’m particularly well known for code craft, TDD, CI, CD, and refactoring.

In recent years, I’ve worked to bring Lean flow to organizations, helping them to reduce unpredictability, delay, and frustrations of typical delivery processes. This has been rewarding and fascinating, and will continue to make a big difference for the companies I’ve served..

I’m living in Scotland. I speak one human language and many programming languages.

The Law of Two Floors

Nobody two levels ABOVE OR BELOW you on the org chart really knows what your days are like.

Obviously, nobody wants to have errors and failures in their system. We would like to see 100% success rates, right? 

Well, hold on…

Pass Rates

No Rejections? That’s incredible!

Competition

Isn’t this “using blame and shame to create an upward spiral”? 

Does it make a difference?

Here is a pipeline based on some factual post-code pipelines:

Looks pretty good, right? Pretty high pass rates?

The overall pass rate is only 58%. 

Let’s run some 100-task simulations. Ideally, each step would run once per task. When a code submission is rejected, it starts back over at the beginning.

The simulation is unfairly simple. 

With this pipeline, 180 extra hours (rework) are needed just to operate the quality gates. That doesn’t include programming or queuing time. 

Costs

Shifting

Do you remember all those rushed changes that your developers implemented three years ago, and how they complained about the design damage they caused to make that happen?
It’s all still in the codebase. It never disappears.
You may have forgotten it, but they still live with it every day.

I’m not saying you were wrong to be in a hurry then; I’m only saying it’s not over

It’s a useful practice, though it can be emotionally intense compared to other ways of work like mob programming AKA teaming AKA ensemble, or swarming. It’s easier for people like me to work with three partners than only one.

The fact that other ways exist in no way diminishes the value of pair programming, and if you aren’t able or aren’t allowed to go to a more inclusive collaborative technique, pair programming is a great way to work.

That is, if you’re doing it correctly and don’t fall into the key dysfunctions…

Here are the resources:

BASICS

• Jeff and I wrote The ABCs of Pair Programming to help you get started.
• Vitaly Sharovetov’s Guide to Pair Programming might be more your style; it’s pretty good!
• Dragan takes us from Async Code Reviews to Co-Creation Patterns with Ben Linders.
• All I Need To Know About Pair Programming, I Learned In Kindergarten by Williams and Kessler. This is often listed as a highly influential paper by experienced pair-programmers.
• Ron Jeffries’ Pair Programming article, written in 1998 describing his actual experiences using this practice in a real corporate project with deadlines.
• Josh Kerievsky illustrated the concept with Pair Drawing.
• Williams and Kessler’s Pair Programming Illuminated, based on significant, reviewed research 
• The description from eXtreme Programming.org
• The Agile Alliance’s article on Pair Programming  
• A very old YouTube video I made

TIPS FOR PRACTITIONERS

• Duckly’s 7 Tips For Successful Pair Programming
• Martin Fowler’s Writings On Pair Programming with Birgitta Böckeler and Nina Siessegger 
• Jeff and I wrote Two Heads are Better Than One for Pragmatic Programmers, describing the benefits that people can expect.
• Note that apparently James Coplein wrote one with the same name (Two Heads are Better Than One) earlier than ours, and it’s not available to me. If you have a link to his, please send it on.
• A mob programming quick-start article by Anthony Sciamanna is also relevant to pair programming. You could be improved by reading everything Anthony writes. 
• If you pair-program in person, configure your space.
• Try some remote pair programming tools. 

DYSFUNCTIONS

• Pair Programming Smells (from AgileInAFlash) by Jeff and myself, again.
• The antipatterns of Programming Under Surveillance instead of pair-programming.
• A video about pair programming dysfunctions

BENEFITS

• Dave Farley’s Pros and Cons of Pair Programming
• Dr. Williams’ the economics of software development “indicates that pair programming is highly productive.”
• Williams, Kessler, Cunningham, and Jeffries: Strengthening the Case for Pair Programming
• Other of Dr Williams research papers and writings.
• Alistair Cockburn’s paper with Dr Williams on The Costs and Benefits of Pair Programming
• David Bernstein’s video on Why Pair Programming is the Future

This is just a start. Sometimes we ship and then refactor …in this case, I have shipped this article knowing it’s not comprehensive and may 

Tool vendor Tuple also has a listicle on pair programming. You might find it useful.

Feel free to suggest other links that you have found helpful, funny, or illuminating.

Also, remember that we teach these skills at Industrial Logic  along with many other technical, management, and UX skills. We’re here to help you be successful. Give us a call.

I understand why people say it. I don’t necessarily agree. It is arguable that relying on developer estimates is at least as irresponsible.

There are interesting counterarguments that I’ll summarize here.

But First, This:

Many arguments lean on “managers need accurate and precise estimates” but if those don’t exist, it seems irresponsible to depend on them. Would you build your entire company’s operating system on Unicorn Poop? That companies are in business despite needing more accuracy and precision than they get suggests that maybe the pinpoint accuracy isn’t as important as we let on.

“Before buying a thing, I need to know the cost!” say some. Software development isn’t like “buying a thing.” It is a collaborative development project. It can’t be what it isn’t. It needs ongoing management involvement.

I don’t expect the above paragraphs to put those arguments to rest. They will be brought out because if estimates were reliable it would make management much easier, and nobody wants management to be incredibly hard. Sadly, it’s only wishful thinking.

George Dinwiddie’s book suggests that we be empathetic toward the managers’ needs and ask what they need the estimates for, how they plan to use them, and how we can help them. I like his approach and recommend his book.

The Responsibility Argument

So, on to the point suggested in the title: is estimation the responsible choice, and looking for other ways an irresponsible choice?

Can we balance these and compare them like-for-like?

Let’s try.

1. Wasting project time estimating and re-estimating (including detailing and estimating work that will never be done) is irresponsible. We see teams wasting many person-weeks per year (often more than 3 person-months) trying to estimate more precisely and accurately, without positive effect. 
2. The estimate is not the duration. Getting people to shorten the estimate doesn’t shorten the duration. Misunderstanding this leads to “sprint packing,” which is an open invitation to cascading schedule failure.
3. Summing inaccurate guesses won’t add up to an accurate number especially when there is pressure to guess low. Pretending it will average out (when it never has) is unrealistic and irresponsible.
4. You can’t make your estimates more precise and accurate than the natural variation in the work. Even setting story points to half-days won’t help with this. See Why Is This So Hard?
5. Estimating harder and more often doesn’t eliminate randomness and variation in the system. Rather than estimating harder, work on becoming more predictable (even if it doesn’t seem faster).
6. Predictability isn’t always what you most need from your teams. Does it make the outcomes better, or only make managing easier? What would you surrender (in time and money) to improve predictability? Would you be willing to allow teams to work differently (perhaps mob programming or TDD) to improve predictability, knowing that it will slow them down in the short term?
7. Proponents of #NoEstimates never claimed you could eliminate every kind of sizing & estimation. It’s just a hashtag. It’s about reducing estimation waste, but the hashtag is the name that stuck. “AHA! You are choosing a day’s worth of work! That’s estimating!” never was the sockdolager one might expect. Proponents take that easily in stride. They recommend forecasting and slicing the work thin – it doesn’t upset them that those are forms of estimation.
8. Managers must work with teams to manage risks. They can’t delegate risk management to developers via estimation. They cannot “quiet quit” management by reducing it to mere scheduling.
9. Managing, again: “How long will it take you to do this in 8 months?” isn’t a question. If the date’s a given, the more important questions are “What do we do first?” and “What can we de-scope to hit the deadline?”

All methods that help teams, managers, and clients work together efficiently to produce a positive outcome without all the irresponsible wastes of typical estimate-heavy systems are welcome under the #NoEstimates banner.

This blog post is unlikely to convince anyone who is of a solid opinion, but maybe it’s helpful to people who want to look at it from multiple angles and who don’t feel threatened by the fact that this hashtag and its concepts exist, nor by the idea that it’s not universally accepted.

Imagine I have to work in an unfamiliar and tough passage of code.

Unprofitable Code

I spend time and effort to puzzle it out, and all I get from it is that now I understand that tough passage.

If it was written in the most primitive way possible, using no interesting language or library features (which might have made it less puzzling) then it is unprofitable.  I have invested my time in “playing computer,” simulating every line of code and tracking each value in my head, or perhaps I walked through every line and watched every variable in a debugger. 

I have expended this effort of will and focus but received little in return. I know what this bit of code is doing (for now) but I won’t be any faster to write or read other code because of it.

That knowledge will be lost in months, possibly weeks or days.

The unprofitable code, left in its original form, will require as much effort next year as it did this time. It is a productivity speed bump.

Profitable Code

OTOH, if I dig into some unfamiliar and tough passage and learn some idioms, standard library functions, built-in syntax, or framework capabilities then I have been rewarded for my pains. 

This is profitable work; I know how to read and write similar code more fluently. It may save me minutes, hours, or even days of work. My investment will pay dividends for a long time.

People familiar with the idioms and method will move quickly through this code, and others will only have to suffer that initial shock of newness once. 

You’ve done it. I watched you do it.

We’ve probably argued about it.

The Defining Dysfunctions

I published a blog post some time ago on the Industrial Logic website about programming together vs programming under surveillance. It’s a relatively simple piece, and it identifies a problem we have in the world when it comes to just about any technique or discipline.

When I suggested that people mistake group programming for working under surveillance, an incredulous reader exclaimed “How could it possibly be anything else!?”

So here’s the thing: a person had a bad experience where instead of actually researching what pair programming is and how it works, they just sat down at a keyboard with another person and tried “doing pair programming” without any pre-study or preparation. They ended with one person bored, watching the other program.  

This is a widely-known dysfunction or “failure pattern” known as “Worker/Watcher.” It’s not how pair programming is done. 

The two people who had this one unpleasant, uninformed, wasteful experience came into it with little more than a sound bite (“two people coding together”), guessed at how it was done (“one person types”), and had a poor experience. 

Since they didn’t start with a good definition of pair programming, that experience became the definition of pair programming. 

They had a defining dysfunction. 

Unless something new happens, they will forever see pair programming as wasteful and pointless practice.

Is that the real definition of pair programming? 

Is that what it’s about and how it’s done? 

Not remotely. but it is the one touch-point they have – the one experience that they have had of it, and “pair programming” is the name of that experience now.

Do they want to try it again? Clearly not. They know what it is, and it’s nonsense. 

They will likely take to social media to decry the BS that is pair programming and save everyone else from this wasteful and unprofitable behavior.

You and I have likely done the same. 

Give those complainers some credit, because at least they tried it (or something that they imagined was it) first.

Some Examples Might Be Useful Here

I ranted against scrum™for years, because I let the dysfunctions I routinely see become the definition of the process for me. If anyone were to actually try doing scrum™it would be a pretty good way of working, but nobody does.

Sadly, a lot of people in that space have adopted the defining dysfunctions. As far as they are concerned the “right way” to do scrum™ is to have a titled person assign individual work tickets to developers, who strive to serve the maximum number of tickets per fortnight to raise the velocity of the team – striving to do “twice the work in half the time” (a soundbite). This isn’t remotely what the defining document of the scrum™ method describes but it is what is often taught as “doing scrum.”

Are you an agile hater because it’s all Jira tickets, meetings, estimation, and work crammed in to meet artificial deadlines? I’d hate that too. I do hate that. It’s just not agile. it’s not even scrum™.

Do you hate agile because agile is “no documentation,” “no design,” and “no estimates”?  Well, that’s a worthy distaste. It’s also a mischaracterization.

Do you hate TDD because you have to write all the tests first, and you don’t even know what shape the answer is going to take, so it’s impossible? Well, that’s a bad process, and it’s not TDD. It’s not the definition of TDD, it’s just a failure mode.

Why Bother Trying?

Sometimes people don’t even have to have a bad experience to adopt a defining dysfunction. They hear a sound bite or title and imagine dysfunctions. They (efficiently) go straight to disdaining the practice based on their imagined defining dysfunctions.

Do you think that Psychological Safety means you can’t ever say anything that might possibly upset someone? Does Radical Candor mean that you can say whatever you want without consequence? Wrong, and wrong. Those are defining guesses at dysfunction. 

If we only guess at a discipline or a philosophy or a behavior and don’t actually bother to investigate what it’s intended to be, what it really means, and how people actually perform it then we don’t have the basis for an honest opinion. If we have only experienced it as a bad attempt at a good idea we haven’t formed a valid opinion. 

We’re Too Smart For That!

Have you jumped to conclusions based on naive attempts or imagination alone?

I’m betting we both have.  It’s a human thing, and we’re all human. It doesn’t much matter how smart or experienced you are – you’ve done this. I might just be projecting, but I’ve seen too many examples to believe it to be less than universal. Please prove me wrong!

I’m willing to bet that you’ve done so this week. Let’s both look out for these mistakes, because I’m betting that we could be more successful at many things if we took the time to understand them.

• Stop using Per-Person Swimlanes
• Swarming
• Pitfalls of solo work
• Programming Under Surveillance, or in groups?
• Faster and More Predictable
• Managing Interruptions
• Work To Be Interruptible
• Scatter-Gather software development
• What is your First Time Through ratio?
• Squeezing Vs Slicing
• Managing Programmer Productivity
• Over-Starting and Under-finishing

An article has been shared with me by several friends and also by some critics, and some people who are both, describing how TDD is fundamentally wrong, and doing test-after-development is better.

To be fair, the process described here is fundamentally wrong:

TDD Is Fundamentally Wrong is Fundamentally Wrong

So What Is TDD?

You can take that straight from the horse’s mouth (so to speak):

Was It A Misunderstanding of the List Method?

Do I disagree with the article, then?

You can specify start dates and/or end dates with options –after and –until.  If you specify neither, you get everything.

This programming idea is not so interesting on its own, and I have multiple expressions that all work just fine. It’s not a programming puzzle I am here to present.

Instead, I’m curious about which version speaks to you, which teaches you, which repulses you. 

More than that, I’m interested in WHY. 

Here is an if-the-else version:

Here is a similar version using a dictionary:

Some people will naturally prefer if/else for the simple reason of familiarity. They see a lot of if/then/else logic, and so there isn’t much to learn or think about. They may call it “simpler’ but it is not. 

The dictionary version has more parts, but they’re very simple parts, and all the actual work is done in the first and last sentence. 

The structural matching is using newer syntax, and is both less verbose than the if/else and more verbose than the dictionary version.

Which strikes you as the most valuable expression of the idea? 

Which would you rather write?

Which would you rather edit?

Which would you rather test? 

What is your reasoning behind the appeal of your chosen method (pun intended).

Even though I’ve been in software a long, long, long time, I hadn’t really studied CSS before last year (shocking, I know) and so I’ve been behind in my training. 

I had an opportunity to dive in more, and all was going well until I started playing with media queries and ran into a specificity problem that wasn’t so obvious (to me, though it may have been to you).

So, to help people who are treading the same path, here are some aids on specificity:

• W3 Schools has a fun “try it and learn” approach to general CSS Specificity
  • Saucelabs specifically breaks down specificity and media queries
    • Halodoc provides some best practices to avoid troubles.
      • Specificity with Darth Vader and Stormtroopers and stuff at smashing magazine.

        
        

        These should get you past the worst of your troubles nicely. If you do get stuck, then it’s always nice to experiment with a local HTML/CSS document or maybe fire up a REPL.IT instance for HTML, CSS, and JS. It’s all fun.

        PS: Because we need it so often, here is a CSS Selector Cheat Sheet.

Enjoy:

• Industrial Logic’s Code Smells album is carefully curated and deftly explained. A winner.
• Industrial Logic also has a cheat sheet for code smells (recommended)
• The OG
• Wikipedia’s extensive listing
• A nice taxonomy at Coding Horror
• A nice writeup at Refactoring Guru
• The Samman Coaching List has nice descriptions.
• There is a longish list without explanations at DevIQ, as a jumping off point for many interesting web searches.
• Arjan Codes (a nice channel, recommended) has a video introduction to Python Code Smells.

It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with “Absolutely Not! Never! That’s wrong! Test via public interfaces.”

I thought a little longer, and said “I’m not sure” and then later “I’m not sure that ‘private’ is even needed.”

This is where the problems started, and maybe here I can clarify what I meant by it all. 

People assume (and insist) that I could only possibly mean that they should substitute ‘public’ for all protected and private members, polluting the interface, and inviting the violation of a class’ internal state. 

That was never my intention and still isn’t. Still, this is what people insist that I must have meant from the start. I suppose this is because that’s what they imagined me to mean and it’s hard to admit that you’re wrong, or perhaps because this is social media so people never miss an opportunity to double-down and pile on if at all possible. It’s like a sport. 

It’s also entirely possible that I didn’t communicate well at all in short tweets. Maybe that’s all on me. I can’t say.

Well, you’ve come this far, so let’s see if I can’t communicate better in blog than in twitter, since I can write in peace without people accusing me of meaning the wrong thing while I try to explain what I actually mean.

If I’ve managed to make sense with this post, let me know. 

If I’ve not, the forum is open for clarifying questions below.

Autocomplete is a big deal.

The good thing about ‘private’ and ‘protected’ – the thing that actually makes programming easier/better, is that the methods aren’t offered by auto-complete. The idea of locking people out of calling the method? Not even remotely a second-degree concern.

People program by autocomplete. You type the name of a thing, press the dot, and you get a list of things you can do. You may never look at the documentation, or read the example code, but you will see the autocomplete hundreds of times a day.

When you want to disable an account, there is likely to be a ‘disable’ method attached to an account. You choose that method, run the tests, ship it. That’s how you normally will navigate.

When you don’t see a method you want, you might pop up a level and use the module or some management API interface. Again, you type the name and a dot, and you look for ‘disable’ in the recommended names. 

Private and Protected are two of the ways to keep functions out of that list, and if they’re not in the list, you’re not likely to even consider calling them.

Arbitrarily Located Functions

Testability of Private Methods? None

When we talk about testing private methods, it’s a non-starter. If you put the word ‘private’ on the front of a method in most languages, you cannot call that method from a test. That means you can’t possibly test private methods.

Okay, there is a way, but it involves reflection and that’s an obscenity. If you ever use reflection to crack into some legacy code and test hidden methods, make sure you remove that hack as soon as humanly possible (or sooner) because it’s a travesty. It’s awful. It will fail you if the method is renamed or moved. Reflection is generally a bad idea, and I wouldn’t do that (much, or for long).

If you are doing TDD (and why wouldn’t you?) you test the public methods, and if they’re using private methods then the private methods are being exercised. If you have meaningful tests and assertions, then the private methods are being tested through the public interface and that’s probably okay.

If you’re not doing TDD (and why not?) then you may not have code that tests all the private behaviors. You may have to read all the code in order to exercise it properly, which is a pain.

If you’re doing test-after development (but why?) you’ve written the code and now you have to write tests around it. Every private method is a called from some public method and you’re going to have to figure out how to get down into that private method code and recognize if it’s working correctly or not.

By being private, those methods have cut off the easiest route to testability – calling the method directly.

Should You Test Implementation?

You should: implementation is how code behaves and you have to test behavior.

There are caveats here:

• If you’re structure-aware in your tests, they’ll resist structural refactoring
• If you’re time-sequence-aware in your tests, they’ll resist time-order refactoring
• If you’re using reflection, you’re poisoning our future and must be stopped (half-grin)

There are rules, of course. You don’t lock down things that you want to change, and you don’t leave unspoken the things that must be true. Your tests specify how your world behaves at a certain level.

Sometimes that’s too high a level and there are mini-behaviors you need to check too.

I’ve seen cases where testing only at the interface required hundreds of tests, but testing at the internal level requires barely a dozen. This is because at the higher level, you need all the combinations of all the paths of all the subordinate functions. At lower levels, you need one for each path in a function.

High-level end-to-end and integration tests take a long time to run, and microtests are cheap and fast.

We tend to do microtesting (or unit testing) so that we can afford to run the tests in a tight TDD cycle. 

To argue against testing implementation functions is to argue against unit testing and microtesting on principle.

If you should only use the most-public interface, then shouldn’t you only test at the UI level? Yeah, this is not a good idea. 

So how can we get at the lower-level functions? If they’re all private, we can’t but it is totally possible if they are public methods on lower-level classes that are composed (“encapsulated”) by the API classes. 

Interfaces and Implementations

In many languages, you can declare a public interface, and that interface can be implemented by other classes.

It’s accepted that one should always program to the interface in those languages. This way, one can only use the declared, public interface of the implementations. This keeps the implementations substitutable (via Liskov Substitution Principle). 

Non-interface methods of the implementers are already hidden: callers have no access to them via the interface. 

If you’re using the interface, and you press the dot, then only methods in the public interface are presented. The other methods of the implementer may as well not exist, because they are not available here.

If you have segregated interfaces, this is even nicer. It may be that two or three public interfaces are the right way to think and design interactions, but combining a few of those interfaces together is the better way to implement the behaviors. No user of one interface has any awareness that the other interfaces exist on the object, nor of the public methods of the other interfaces, nor any of the public methods of the implementers.

In order to reach the public methods of the implementer, a caller would have to down-cast from the interface to the implementation (a no-no that justifies a sharp crack across the knuckles with a yardstick) in order to even know that other methods exist. 

This is convenient. This means that all methods of the implementers can be public without exposing those methods to callers.  Since they’re public, you can write tests directly against them. Because the implementation is being tested also through the interface, it’s easy to ensure that it behaves as a whole implementation.

Why not make them private? Because it’s redundant and limits testing. 

Without polluting the public interface, one has a fully open and testable class.

Thinking a little more deeply

1. In a Rat’s Nest:
   sometimes people are doing test-last (after coding) and they have a complex method. You shouldn’t have big, complex methods if you have any other choice. To try to manage the complexity, they may extract some private methods.
   In order to test through the API, you have to navigate the rat’s nest. You will have to set up deep data structures and some combination of boolean conditions that will allow you to get to the private method’s function call, and then to exercise the code inside that method.
   It’s easier to make the method’s access less restricted and test it directly than to have dozens of long and complicated tests. Perhaps package-public, perhaps protected so you can cheat with inherit-to-expose. 
   It’s better to test the code easily than to write awful, fragile, internals-aware tests.
2. Missed Abstractions
   Where one class has a bunch of private methods, often there is some cohesion between those methods. If one were to set the private methods side-by-side, one might recognize that there have been missed abstractions.
   Maybe some of the methods are generic string, date, or math functions. These could be public methods in a utility package or more-primitive type. If you move them to the “right” place, they can be fully testable and can be reused within the codebase. They would not be public methods of the class you’re working on.
   Perhaps some of those represent a lower-level concept that is munged into the current class. If they were pulled out, they could become testable, public methods on the new class. They would still not appear in the public interface of the class you’re working on.
   
3. In Languages without Private
   In Python, smalltalk, and similar languages there’s no ‘private’ and we’ve been okay with that for a long time (since the 70s for Smalltalk). 
   While people say that encapsulation is a core feature of OOD (and it is) it isn’t the “private” keyword that causes encapsulation. It’s done via composition.
   In a Python module, you can choose what classes you expose and which you don’t. You have a class with a public API, which is composed of classes/functions that aren’t part of the public API. They’re tested directly within the module and don’t have a “private” keyword associated with them. They might not have underscore-decorated names or any other semblance of access protections. 
   
4. Other APIs
   In any language, the Model class or the API class may have a simple interface into the module (as described above) but the module may have a lot of complicated functions and logic divided into multiple classes and functions. 
   The model class doesn’t have any ‘private’ methods at all - it just calls the public methods of other classes in the module. Those classes have copious tests and may not have any methods declared Private or Protected, because only the API and tests call those methods - they’re not visible to the outside world (protection from Hyrum’s Law)
   

So What Do You Do Instead