12 ms·

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pit

• elwell 12y ago
  But I think the main reason for choosing the word "slow" is to bring to mind its connection with the Slow Movement [0]; as the author mentioned. [0] - https://en.wikipedia.org/wiki/Slow_Movement https://en.wikipedia.org/wiki/Slow_Movement
  • spacecowboy_lon 12y ago
    from what I understand the slow movement came out of the hard left in italy - and from what hhe told me the internet is still regarded as a yankee/capitalist plot based on his experiance trying to sell the idea of .coop to italian coop's
• kenrikm 12y ago
  I see it like a Craftsman woodworker vs a high school shop class. At the end of the day they can both build a birdhouse though the quality of final result will be very different.
  • wellpast 12y ago
    Yep -- and I argue that the craftsman can finish at least as fast as the shop student. When someone says "I don't have time to make it sound", they're really saying "I don't have the skills." By the way, I think these skills can be acquired and even taught. They just aren't yet being taught afaik.
    • einhverfr 12y ago
      I would also bet that the craftsman will show less overt progress as he works. He will appear to be moving slower, but will in fact complete the three to requirements faster. And in the initial phase, in particular, the craftsman may take a lot more time. The speed will be shown not over the initial design, but over the whole production cycle.
• hasenj 12y ago
  I think we can learn from some other (not-so-obviously-related) disciplines. The game of go[0] has a ranking system where players progress from 30kyu (complete beginner) to 1kyu, then 1dan to 9dan (very strong). [0]: http://en.wikipedia.org/wiki/Go_ranks_and_ratings http://en.wikipedia.org/wiki/Go_ranks_and_ratings It's mostly statistical and based around comparing your skill level to other players. While a 7kyu level is not necessarily that well defined, and might differ between different ranking systems, there's still a meaning to the difference between the levels. When a 5kyu (stronger) is playing a 7kyu, the 7kyu player is given 2 stones in advance (handicap) to make the game even. The number of stones given as a handicap is determined by (or defines) the difference in levels. It's not immediately obvious how such a system could be adapted for programming skills. But the idea of having levels, and having ways to measure one's level, is very interesting, and might be quite useful. Japanese (and probably other languages) have standardized tests[1] to determine one's language abilities. [1]: http://en.wikipedia.org/wiki/Japanese-Language_Proficiency_Test http://en.wikipedia.org/wiki/Japanese-Language_Proficiency_T... You don't take a test to determine your level. Rather, you take a test designed for a particular level. You either pass or fail. N5 is the lowest level (beginner) N1 is the strongest level (near-native or even better maybe) When you feel you are at say, level N3, you take the N3 test, and if you pass, then you can say that you have passed the N3 test. If you fail, you just fail. It doesn't mean you are N4 or N5. (As far as I know - I might actually be wrong here). I wonder if some standardized tests can be, in principle, constructed to measure programming abilities. The tests must be crafted such that, even if all the questions are known to the public, then studying for the test is the same thing as studying to build up your skill level.
  • pjmorris 12y ago
    Should you measure the worker, or measure the work? Anyone who can build reliable systems using unreliable parts (like humans) will have an edge. EDIT: If you're going to measure the worker's programming concept knowledge, Alison Tew's work seems to be at the leading edge. [1] 'Developing a Validated Assessment of Fundamental CS1 Concepts', Tew, Guzdial, http://dl.acm.org/citation.cfm?id=1734297 http://dl.acm.org/citation.cfm?id=1734297
    • 12y ago
• mVChr 12y ago
  I think of it more like "deep" and "shallow".
  • kaichanvong 12y ago
    Mindful and considerate to your future self and others.
• Argorak 12y ago
  > I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which sometimes needs a step back and a look at things. So, if I came to work "zügig", I didn't speed, but there was no traffic jam, I didn't stop for a coffee somewhere, etc.
  • barking 12y ago
    Zügig is just so..Germanic! It's exactly how I imagine the stereotype of German efficiency. In the anglo-saxon world we pride ourselves on how many hours we work. In Germany they work fewer hours and produce more and of better quality. At least that's my impression.
    • lectrick 12y ago
      Relevant: http://knote.com/2014/11/10/why-germans-work-fewer-hours-but-produce-more-a-study-in-culture/ http://knote.com/2014/11/10/why-germans-work-fewer-hours-but...
      • rapind 12y ago
        I now love german culture. It's like finding my soulmate.
        • jsilence 12y ago
          Please note that another german culture is to be overly pedantic in following rules, no matter if their initial intention applies or whether we just set them five minutes ago. Rules are followed because. This culture makes administrative processes bulky and tedious and tiring. It often fuels my Ungeduld, because I want to get st done zügig.
          • 12y ago
• deleted 12y ago
  [deleted]
• sophacles 12y ago
  > I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. I like to use the word "deliberate" when I mean "slow", but think that "slow" will be misinterpreted.
• pekk 12y ago
  It takes a certain amount of time to build a house (that will be durable and to code) no matter how much people want "skill sets". If it takes a longer time than management wanted for something to be built, that isn't necessarily because "skill sets" are lacking. If the product is shoddy, that is probably not because the team lacked the magical ability to make sound products instantly, but because the team was rushed (on the theory that they are not professionals and have to be micromanaged) The odds are that the feature spec was bloated and management was bad at estimation (perhaps because they demanded estimates out of programmers who are also not good at estimation, in a bid to squeeze as much output from them as possible). Hackers aren't the problem. A pogrom on "hackers" is unlikely to solve anything. "Professional" in the sense of wearing this or that, or following whatever you personally consider to be best practices isn't going to fix scope creep, wrong estimation, fundamental facts about project coordination, or the laws of physics. Building serious stuff takes time. It's management's job to handle that without flipping its shit.
  • Ma8ee 12y ago
    The problem is that anyone who know how to attach two boards with a few nails think they know how to build a house.
  • wellpast 12y ago
    I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to properly engineer software -- they haven't been taught nor had the time to learn it. It's absolutely an issue of skill sets. Yes, management and project estimation are other issues to work out. I'd say we're actually much further along on these fronts than we are on the technical skill sets front. That is, the skill set of building architecturally sound systems.* * Note: I do believe there is a time trade off between features and feature flexibility -- but there is no time trade off necessary for achieving architectural soundness, again so long as the right (presently rare) skill sets are present.
• dvanduzer 12y ago
  The terminology likely derives from the "slow food" movement, which is simply the opposite of fast food. The fast food industry did not "win" the restaurant industry; it did succesfully quantify the (minimal) skillsets around manufacturing food.
• eric_h 12y ago
  I think "well considered" is a better adjective than slow.
  • wellpast 12y ago
    "Well considered" is too subjective, I think. There are specific, concrete skill sets that lead to systems with specific, well-defined properties (i.e., architectural soundness). Your system may be well-considered but if it's not architecturally sound it's going to increasingly tumble over time.
• AgentIcarus 12y ago
  This seems similar to michaelochurch's thinking about 'guilds' - which I guess is a precursor to formalised 'engineers' or master craftsmen, which is something Software 'Engineering' seems to be in dire need of.
  • badubu 12y ago
    When was the last time you engaged a journeyman carpenter? This problem runs much deeper than just software. Any skilled craft is always at odds with a manager/employer/clients view that you are a fungible asset.
  • justincormack 12y ago
    I recommend Richard Sennett's book The Craftsman, which talks about both the history of craft and software.
• popee 12y ago
  Yeah, absolutely wrong nomenclature and it would be better to call it: http://en.wikipedia.org/wiki/Wu_wei http://en.wikipedia.org/wiki/Wu_wei > Wu wei is an important concept in Taoism that literally means non-action or non-doing ie. "effortless doing" Set goal, think and explore a little, rest a lot and wait until you get clear picture. Then and only then start coding. Pros: No burnouts, less stress, etc, and constantly moving forward (in contrast to 2 steps forward 1 step back cycle) what results in overall faster progress. Cons: Personally it's sometimes pain in the ass to wait, but it's important to understand -> not to be obsessed with job. Get a hobby, do something else and let unconscious part of your brain deal with what needs to be done -> mind blowing discovery for me that actually works, but still have to get used to this concept :-)
• tomphoolery 12y ago
  > I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Agreed. The ideas in this article are sound, but I'm not sold on this "slow programming" term. It's more like "careful" programming, or how about "care-full" programming, in which you put your full amount of care into every character you write. The reason we've been able to speed things up is because of these tools, like CI systems and test frameworks. Faster iteration means getting results back faster and that means you can spend more time thinking about the problem and less time implementing it. That is the major benefit of what the author calls "fast programming" and it's something he glossed over completely. Just because you move fast doesn't mean you can't be careful along the way. You just need tools that extend your own visibility in order to catch problems faster and more accurately solve them.
  • Retra 12y ago
    Careful is a good way of putting it. It's possible to change the entire world in half a page of code. That should be the goal...
  • sethammons 12y ago
    I like "deliberate" programming -- though, the syllable count may be too high.
• jchrisa 12y ago
  There's also the question of what you work on, not just the quality of your work. You can do a barely-works version of something that it turns out people really want and it's better than if no-one had built it... Maybe slow programming means finding important things to work on.
• forgottenpass 12y ago
  With specific skill sets, you can build architecturally sound systems at no extra cost. Except the extra labor costs of someone with that skillset.
  • fsloth 12y ago
    I would like to respond that the maintenance costs and thus TCO will be lower for the better designed system - however I have no idea how to formulate this into a tenable economic argument since I have absolutely no data to back this up.
  • wellpast 12y ago
    Today, yes. But that's a problem our industry needs to solve. A lot of our labor force has already paid in money and time for education. Our education system has simply failed to deliver the full skill sets. Not necessarily the education system's fault -- our industry needs to know what skill sets to ask for and what is their value.
    • forgottenpass 12y ago
      Our education system has simply failed to deliver the full skill sets. Even if you ignore the question of what material post secondary education should be teaching, the more substantial bounds are the time limitation of school. Even a hyper-specialized curriculum can't cover everything, and isn't a substitute for real world experience. It's soothing to sit around and find ways to opine and blame external parties (education is a popular choice) for the fact that experienced and skilled developers can't be had for the cost of green developers. But it's just an activity that releases energy without changing anything, aka (mental) masturbation.
• briantakita 12y ago
  Instead of slow, continuously evolving the domain abstractions is key. Faster & more effective is better. If slow creates effective judgement instead of prejudice, then go slow. There are two systems in the brain at play. "Fast thinking" involves gut reactions & intuition. "Slow thinking" involves logical analysis & formations of models. Both contribute to effective solutions. Recognizing iteration as the cycle of evolution & growth creates working systems in congruence with natural law.
• deleted 12y ago
  [deleted]
• einhverfr 12y ago
  I am not so sure. The point of "slow programming" is the same as "slow food" and "slow democracy." I think you have to see the three together. The point is to slow down, deliberate, and then do. That doesn't mean long iterations, nor does it mean deferring progress. It means ensuring solidity of the progress as you make it. I once interviewed for a job at one of the most recognized and big Perl shops in the world and didn't get invited to face to face because I "took my time" with their puzzles. My response was that my first drafts were faulty, and that I preferred to program slowly because I could deliver more code, faster, and better by taking my time with it. In the end, their loss. Deliberation is important. That often means slower apparent progress but faster progress overall.
  • duncanawoods 12y ago
    Yep - there are benefits to a slogan being counter-intuitive because the whole point is to challenge the intuitive way of approaching a problem and making you see it anew. In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things. In this case the equivalent slogan might be "Do it right and ship it late" i.e. its so important to get it right its worth risking missing a shipping date. Practical principles, like the agile manifesto, describe a preferred trade-off rather than just naming a good attribute like swiftness, because who doesn't want the good attribute? It would be irrational. I think this also highlights why moving faster is nearly always better even if uncomfortable for some: its a more effective way of handling uncertainty and learning faster that in most commercial environments is more important than quality. Quality in the wrong places is waste.
    • einhverfr 12y ago
      I am not sure that ship it late necessarily becomes a part of slow coding. The point is to code deliberately and with quality. Once you have a production codebase, if you do things right, there's no reason you can't ship on a fixed schedule. You might ship less initially than you expected, but in the long run, you will ship more than you expect, because the delay of design pays back later.
• michaelochurch 12y ago
  I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. I think a better adjective would be robust. But I'd hate "Robust Programming" become as much of an abortion as "Agile", now an excuse for micromanagement and business-side mediocrity, has proved itself to be.
  • danenania 12y ago
    I agree about what the term 'agile' has become, but in many situations (especially in startups), spending too much time and energy to make something robust in version 1 is worse than hacking it together with spaghetti code. The key is to know which mode is appropriate for what you're doing. If we want to create more tolerance for good engineering practice, we can't act like primadonna artists obsessed with building our perfect masterpieces on someone else's dime. We're hired by businesses, so our arguments need to be grounded in business value. "It's a shitty architecture" isn't going to get you anywhere. "It's going to fall apart and cost you millions if you do it that way, but if you take out these less important features and spent more time on what matters, we can do it right for the same cost..." People might just listen to that one.
• calinet6 12y ago
  The best and most concise way I've found to explain this is a systems focus. We aim to focus on systems, because it is the most efficient way to work. By using good methods, designing complex systems well, and spending adequate time designing, we achieve a net speed increase, productivity increase, cost decrease, and additional positive benefits such as programmer morale and overall quality. In my mind, quality is the genesis of everything, but you do have to word that really well so that the overlords comprehend the consequences correctly.
• rumcajz 12y ago
  Programmers are craftsmen. They need vocational schools. Academia is not up to the job.
  • wmt 12y ago
    That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering. There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers. It would require a major effort to first study the existing emergent software craftsmanship practices to find common patterns and to scientifically evaluate their effectiveness, and the results would have to be taught in the hypothetical future curriculum where future software engineers would be made. Then we might have software engineering instead of just software craftsmanship. It's almost a bit amazing that software "engineers" who can be very obsessive about getting the data or A/B-testing will craft software based on methods they have no data about.
    • jwmerrill 12y ago
      > There have been very few scientific studies about the basics of building software... There hasn't been a lot of great quantitative scientific study on how to productively do science either. Academic science is a craft, and is more or less learned through apprenticeships. I'm trained as a physicist, and I'm certainly a fan of quantitative scientific methods, but I think it's important to realize that there are some areas where quantitative science is effective and rewards the required work well, and other areas where it is largely an ineffective waste of time. I suspect trying to quantitatively study things like "how much unit tests really affects the bug density" is one of these cases with a poor reward to effort ratio. There's a danger in trying to apply quantitative science to complex phenomena, when many or most relevant factors are actually uncontrolled and unmeasured. Once you have a number--any number--the tendency is to fetishize it at the expense of broader thinking. Make no mistake: quantitative measurements of the behavior of people performing complicated tasks do not carry the same epistemological force as quantitative measurements of the magnetic dipole moment of the electron. Scientists themselves more typically try to understand their own craft through case studies and "professional wisdom" passed down from practicing experts to apprentices. Software developers would probably do well to (continue to) do the same.
• diltonm 12y ago
  >> "slow" is going to be self-defeating nomenclature It's pointed, poignant and accurate as well as precise; self-defeating it is not.
• Floegipoky 12y ago
  Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. You are right that most people that come out of university are woefully unprepared to design software systems. However, that doesn't change the fact that what ends up being the "best" design in the end is rarely apparent (or appropriate) in the initial planning stages of a software project. Requirements change, and the architecture needs to adapt with them. These architectural changes do have a very real cost. The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed, and that the longer the refactoring is deferred, the more expensive it will be.
  • dlitz 12y ago
    > The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed If you're worried about that, then the problem is that you have someone managing a software project who doesn't know how to manage software projects. That's not a failure of the methodology; it's a failure organizational design.
  • runeks 12y ago
    > Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. Most likely, not a lot of things compare to building houses in all aspects. The point is, if developers are having problems wrt. scaling, then we need to build tools that abstract away scale. Define a language that allows the runtime to auto-scale, depending on load. As far as I can see, it's "just" another engineering challenge, not essentially different from figuring out how to make a skyscraper withstand heavy winds.
• adwelly 12y ago
  Deliberate Programming might be a better term; it encompasses the idea of steady progress, and solid intent. - update - I see this has already been suggested. Still like it...
• tomelders 12y ago
  There's an old turn of phrase from the building industry which can to mind while reading this article, and I think it sums it up perfectly. "Measure twice, cut once" I'd argue that a lot of projects these days suffer a death of a thousand cuts.
• john_b 12y ago
  You are probably right about the marketability of "slow" as a movement, but in hacker circles these ideas need to be discussed honestly and directly. The analogy with house building is flawed. Home construction generally follows a preplanned architecture, schedule, and process that has been refined and tested over a long time in an environment which doesn't change much over time. The process of building houses is well understood and if a delay occurs it can be attributed to a lack of skills as you say (or funding problems, etc). Software has a different nature. If you have thoroughly solved a problem, the solution can often be automated. There is no button you can press to build the same house you built once before. It still takes time, money, and materials. With software, if you are not spending a large portion of your time working on a problem that has a novel component or two, you or someone else has probably failed to automate enough. As a result, you never quite possess the necessary skill set to solve your current task. You are always pushing some boundary, even if small. Gross skill set mismatch is a separate problem, of course, but a transient skill mismatch is an inherent aspect of good software development and I don't think it's justified to place any blame on moderate and transient skill mismatches as a result. Whenever you are dealing with something novel, you will need to go slower than usual. It's the same for new types of buildings that use newer construction tools or technology.
• dceddia 12y ago
  How do developers currently learn to build scalable, maintainable, well-architected systems? Certainly there are some books on the subject, and that might be a good start, but I'd be willing to bet that these skills are largely learned "on the job" through a bunch of trial and error. Are there any good ways to dive in and get experience with a lot of smaller examples, similar to the "code school" approach but for more advanced topics and systems? Maybe we need something like that. Code School: Advanced. There's a lot of thought going into training the next generation of software engineers from the ground up, but there doesn't seem to be much work toward improving the skills of the ones who already have a bit of experience.
  • marktangotango 12y ago
    It is all trial and error from my perspective. I like this line of inquery. The problem I see is the technology is constantly changing, and the meaning of 'scalable' is always expanding. Ie the 'Enterprise' archticture of the past didn't scale to 'internet scale', will 'internet scale' scale to 'internet of things' scale?
    • dceddia 12y ago
      That's a good point -- things are constantly evolving and current tech becomes outdated so quickly. At the same time though, I think it supports my point that the training for these kinds of things should be faster than reading a big thick book followed by a bunch of trial and error.
• jessedhillon 12y ago
  "Deliberate Programming"?