Comment by dragontamer | Hacker News Reader

Comment by dragontamer | Hacker News Reader

I've been reading "Large Scale C++" by Lakos. There are two kinds of code Lakos writes about:

1. Application code -- Fast changing, poorly specified code. You need to have a rapid development cycle, "discovering" what the customer wants. Your #1 job is pleasing the customer, as quickly, and as reliably, as possible.

2. Library code -- Slow changing, highly specified code. You have a long, conservative development cycle. Your #1 job is supporting application programmers.

TDD probably works for #2, less so for #1. Furthermore, we all dream of being library developers (that our code and specifications are stable, and that our code can last decades). Alas, most of us are Application developers, and the lifespan of our code isn't really that long.

Recognizing the lifespan of your code, as well as the innate goals of your team (quick and dirty application style, or slow and careful library style) is important.

------------

Mixing up the styles causes issues. If you write library-style code for an application, the specification will change under your feet and everything needs to be rewritten to the new whims of your new customers.

If you write application-style code for a library, you yourself won't be "stable enough" to support your peers, and no one will want to use your library.

This is something that is touched upon much. TDD fits library writing like glove because the developer naturally thinking of the public contract of its components.

This not to say that Application Code doesn't need the same approach but its a lot harder for developers who don't have their design hats to think of pieces of their functionality as contracts of behaviour that contribute to a feature or requirement. To your point to think of in terms of the life of their code.

I think the top comment links to an excellent talk on TDD and how it is often misapplied.

Determining which is which is definitely a skill developed from experience. For example, being able to see that if every time you use library part Y, you have to add algorithm X around it, algorithm X should be a part of the library not the app.

I find this application/library distinction hard to reconsile with the many long-lived, stable applications that exist. AutoCAD, for example, is older than I am.

Hasn't Autocad been around since before TTD became mainstream?

AutoCAD is an interesting example because it is consumed by professionals much in the same way a library is used by programmers. I think you'd want to be a little slower moving in that space than you would for your average application.

Any large scale program will have both "application" parts and "library" parts.

Lets take Autocad as a long-running example. Its first release was 1982, and had an update this year, in 2020. What's a good example of "application" vs "library" code here?

Lets take the user interface, which is almost always "application" style, with short lifespans. Back in 1982, you probably had to write a custom serial-communicator to interface with the mouse (or trackball). Eventually, Windows is released and a standard mouse-interface becomes common practice.

-------

A few decades later, the 3-button mouse with scrollwheel (with the wheel being the 3rd button) becomes popular. Adding new features to the application, and the overall design of the UI would have to change for modern sensibilities.

Then Ribbon happens. Hate it or love it, Windows programs are now Ribbon-based. Gotta overhaul the UI AGAIN to match the changing times.

This progression from 2-button mouse -> Windows driven mouse -> 3-button mouse with scrollwheel -> Ribbon -> touch-enabled (??) is "Application code", requirements that change with the times. Every few years, the code interfacing with the user was largely rewritten, to match the (then modern) expectations of its userbase.

-------

Of course, there's the "library chunk", which probably solves geometric constraints or something like that. That part may have never changed throughout the life of AutoCAD.

-------

Application code CHANGES. That's the important bit. You cannot expect applications to look the same over decades. I'd be very surprised if AutoCAD still had their DOS GUI laying around (https://www.scan2cad.com/wp-content/uploads/2016/06/autocad_...). That sort of code is thrown away when it is no longer fashionable.

But wouldn't AutoCAD be split into library and application parts internally? For instance, ShapeManager is the internal geometric modeling kernel used by AutoCAD.

I think this distinction is harmful. Your application code should include areas that function as "library code." We do this at work with an explicit UI library that we package separately, but there's no reason it needs to be packaged separately, just create directories that represent some library-esque element of your application and heavily test it and write docs for it, like you would a library.

The distinction is helpful from an organizational perspective.

From a manager's point of view, they need to know where the money is going. If ProjectA is the "support" for LibraryA (and the managers don't know about it), it will look like ProjectA is costing more and behind-schedule.

But if you explicitly split into ProjectA + LibraryA, the managers can see where the money is going, and better allocate funds matching the business's priorities.

Financially: the goal of LibraryA is to outlive ProjectA. There's no financial incentive for ProjectA to think long-term. (And if ProjectA is thinking long-term, then STOP THINKING LONGTERM!! A huge amount of code is short-term glue logic with bad specifications). Aligning your technical goals with your soft-managerial goals is key to survival.

I'm not sure what you're finding harmful when it sounds to me like you're agreeing. Your "library code" (or library-esq elements) is the code that you find needs to be tested more heavily, because it is library code? I don't thing whether it's packaged separately was key to that, but it can help.

Anyone can be a library developer! Unfortunately no one pays library developers, so nearly every programmer is paid to be an application developer.

The economics of application vs library programmers is a managerial decision.

Any application project that starts writing library-style code will slow down, and possibly gain the scrutiny of the managers / executives. In "Large Scale C++", Lakos notes the importance of manager-level buy in. You must have a library-team, with a separate stream of money, if you expect to be sustainable.

Application-style programmers trying to make a library on their own will lose the economic game.

--------

"Who pays for the library??". Well, if your organization has 10 teams, all using a specific library (or that could benefit from a hypothetical library), its actually a very difficult question. This is where hierarchy and management must step in to solve the issue. No sane manager wants to spend their own money helping other teams with no recognition!

Trying to write a library without solving the long-term economic and managerial issues is suicide. You'll only slow down your own application and make your own project look weaker compared to your peers (at least in the short term. In the long term, the library code will blossom and make your team more productive. But surviving the short term is a major concern in reality)

> Unfortunately no one pays library developers

Shameless plug: We're hiring at talkjs.com. Our entire product is essentially a library.

Also, back on topic, our tests never go stale because we promise full backward compat to our customers, no matter what. Solves a big part of the downsides of TDD or other approaches that yield lots of tests.

I was going to write something similar, but i think you have said it better than I would have.

Reply on news.ycombinator.com