Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> write programs that do one thing and do it well. Write programs to work together.

ASIDE: Just been reading The Wealth of Nations, and Smith talks about the "division of labour", which is similar to this specialisation. By concentrating on one task, a workman can increase his dexterity at it, not waste time switching between tasks, and find ways to do it better. "Do one thing and do it well" is a pithy exaggeration of this specialisation.

This division of labour is only possible because of trade: other workmen do the tasks that you aren't doing, and you barter with each other to get what you each need. Because you specialised, you each do your own task more efficiently, so you are both better off. Programs that "work together" is similar, because if you couldn't use another program, you'd have to include it in the first program. "Programs" would also include 3rd party libraries and frameworks I think.

He goes onto say that one limitation on how much labour can be divided is the market size: you to be able to trade what you make. If people don't need much of what you produce, you've over-specialised. However, if you have access to a large enough market, then in aggregate, with many people using a little bit, you can survive. Larger markets therefore allow more specialisation, and therefore more wealth. Rich civilisations grew up around navigable rivers (especially with canals), and inland seas (calmer and safer to navigate than the open ocean), because water-carriage facilitates trade with more people (larger market), over larger distances, at lower transport cost and less risk.

Does the analogy fall down with free programs, since you won't go out of business just because few people use it? Open source projects do seem to need users, for encouragement, bug reports, spreading the word, contributing bug fixes etc - users pay in attention, not money. Without attention, projects die.

Does the analogy fall down when it's the same person writing all the separate programs? You can certainly specialise, and therefore do a better job; and also "exchange" data between those parts. (Provided of course that specialisation is actually more efficient, and outweighs the costs of exchange). But the motivation doesn't apply in quite the same way, since the parts of the code don't get paid - not in money, not in attention. You're more like a communistic planned economy (or, within a firm).

But the interesting point I've been leading up to is: does a larger market for programs lead to greater specialisation? For example, Java has a large number of users, and has a ton of 3rd party programs - and that does seem to include very specialised libraries.

Or, are other factors at work, leading to more one-package programs, such as Word; or dividing the market into smaller ecosystems, such as Java itself, and also other languages python/ruby/PHP, and even frameworks, like RoR. There are barriers between these "markets", in the extra difficulty of using library from one platform in another. For example, for JS, I get the impression there are many libraries for doing the same web/forms/template etc. While competition is healthy, and these frameworks are definitely improving on each other, they aren't the "division of labour" of interest to this particular discussion.

In programs, does a larger "market" of fellow coders result in more specialisation in the "one thing" done well?



A program doesnt getter better by doing the same task over and over again ( and i disagree with A.Smith anyway , a factory worker doesnt choose what process he is going to use to acheive his task , no matter how many times he executes his task , the way he has to work is decided by his boss, A.Smith is and has been proven wrong on many things like the invisible hand");


I've never read The Wealth of Nations, but Smith wrote well before the industrial revolution. So when he spoke of workers, he was referring to tradesmen and craftsmen. For them, specialization does allow them to get better by performing the same tasks over and over again.

In a way, the industrial revolution just changed the scope of his arguments, but I think the basic idea still holds. Now, instead of thinking in terms of a single worker, we could instead think in terms of a single factory. Each factory, comprised of many workers, would then be able to perform one specialized task well, and trade for the rest. It would be up to each factory to organize itself in an optimal manner.

In thinking in terms of a program, it wouldn't be the program that gets better, but the programmer. If they write a program to perform task X multiple times, that program will inevitably get better with each iteration. So, ideally, what you end up with is a series of optimized programs that can work together in different configurations in order to perform different tasks in the most efficient way.

At least, that would be the theory. I'll leave discussions of the invisible hand of the market for later :)


Smith's view of specialization is not the same as today's "interchangeable cogs" view of disposable labor. He's talking about skilled crafts- and trades-man who can both use specialized machinery and acquire skill in its use, as well as avoiding the task-switching costs of single-person fabrication. Smith talks of market clearing not in hours or days, but months and years. His view of labor mobility tends to be generational rather than of a person having multiple careers in a single lifetime, as is the present fashion.

And while a given software program on its own won't generally improve performance over time (absent some learning and adaptive algorithms, though these are still in very limited use), in an appropriate (e.g.: Free Software or other iterative / continuous improvement) environment, coders will make incremental changes to code, which is far easier to accomplish when a program does a single, clearly identifiable task (or can be divided into modules which perform similarly).

Smith's use of the "invisible hand" analogy is a grossly misinterpreted and minor element within The Wealth of Nations.


Code that is organized so that it minimizes context switches is ofen faster and more efficient than code that doesn't.

E.g. sometimes this code:

  foreach (x in xs)
      F(x);

   foreach (x in xs)
      G(x);

   foreach (x in xs)
      H(x);
is faster/more efficient than this:

   foreach (x in xs)
   {
        F(x);
        G(x);
        H(x);
   }


I disagree. When I write a program, I find more and more of bugs the more often I run it. Just as the tradesmen refine their skills, I'm refining my program. (Both are our outputs.)

In addition, by being small and focused, my program will expose more of its bugs for each run because a higher proportion of the code is exercised. (Assuming that we're not talking about the exact same inputs, just like a tradesworker has some variability to work within.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: