17 ms·

The Case for Slow Programming

• PythonicAlpha 12y ago
  The best solutions don't come from hacking, but by grasping the problem and it's full scope, the chance raises that you find a solution that can not only be used for the current problem, but also for similar other problems. A good programmer always tries to find similarities and to reuse old solutions in as many other areas as possible, but not more. Such a behavior also boosts the maintainability of the solution. On the other hand, when it is ignored, a solution quickly can become unmaintainable and the solution that was implemented so "quickly" can become a black hole of man power. I personally experienced more than one project, where the source code has become in very short time so complex and so bug ridden, that development times literally exploded.
• deleted 12y ago
  [deleted]
• elwell 12y ago
  Brings to mind Rich Hickey's support of so-called "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc https://www.youtube.com/watch?v=f84n5oFoZBc
• Adam89 12y ago
  How does typing speed affect the design of software? Thinking about your design has not got a lot to do with the speed you type at. Secondly as programmers we should be able to work on the same code base.
  • swalsh 12y ago
    As women we should be able to birth the same babies? After the baby is born anyone can raise the child, some better than others, but its easy. We call that adoption. Until its born though, the baby, and it's mother are symbiotically connected to each other. I think this is similar to the process of programming. Break down an interface, and work on a team at that level. Behind the interface though, keep it small. one or two people max if possible, and those people have to be on exactly the same brain wave as each other. Even well planned code takes some time to stabilize, and it's hard to even find that if other people are actively changing interfaces etc.
    • baddox 12y ago
      That analogy only seems to work well if the software you're developing can autonomously interact with other software, like how humans can interact with other humans.
    • Adam89 12y ago
      I really like that analogy but am not sure if that's what the author was alluding to. Besides the one thing I strongly disagree with is how typing slow can help you produce better software. Taking time and thinking about your design certainly does help but typing slowly and taking your time designing are not the same thing.
• ludoo 12y ago
  Very well put. I have a similar (slightly younger) age, and often pose myself the same set of questions on speed, tooling, typing. Needless to say, my answers are very similar to yours. As for the Design Process, it works in the exact same way you describe in other fields like Architecture, which I studied and practiced ages ago at a more than decent level. Money (VCs'), the myth of the young billionaire, and a few other things are probably what make developing different.
• serve_yay 12y ago
  > The casualty of my being a slow programmer among fast programmers was a form of dysrhythmia – whereby my coding rhythm got aliased out of existence by the pummeling of other coders’ machine gun iterations. My programming style is defined by organic arcs of different sizes and timescales... Boy oh boy. Look, I'm all for coding slow, taking time and understanding what you're doing. But there is something to be said for "playing well with others". We're all trying to make things, not be the backdrop for your exquisitely-crafted sense of craft. To me that reads a lot like "I would have done something really good if I weren't surrounded by those philistines". Well, maybe so, but you are surrounded by them. So choosing a method of working that does not result in "dysrhythmia" or whatever strikes me as rather prudent.
  • jerf 12y ago
    "Everyone around you is building this bridge in clay.... what are you doing fooling around with this 'steel' crap for?" Of course you can spin it the other way too, which just goes to show this isn't a useful comment. Don't do what everybody else is doing just because they're doing it, do the right thing. If that does happen to be clay, great, but there's a great deal more people using inappropriately sloppy engineering than people using inappropriately careful engineering, so I'd expect to hear a lot more about the former. The only people in real life that I've met that I would consider saying were being inappropriately careful were really just masking fundamental incompetence under a veneer of concern about process. I'm not sure I've ever seen anybody correctly apply massive overengineering to a programming task in real life. I'm absolutely sure it has happened, but it is not common enough to be worth talking about.
    • serve_yay 12y ago
      Don't do what everyone else does if you can do something better that leads to better results. The last part matters -- otherwise you're just crapping on everyone who can go faster than you and attributing the difference to "quality" (conveniently left nebulously defined). Put another way, how do you know what you're working with is steel, and others clay? What if your "steel" is really just clay that is slower to produce and more brittle? How do you reassure yourself that this isn't the case? The answer is, make a big deal about going slower and drink tea and stroke your beard and say "hmmmm." and lots of other things that connote wisdom but do not actually bring it to bear. I am extremely skeptical of all this, not because I am unsympathetic but rather the contrary. We can get extremely wrapped up in our signifiers of skill and wisdom, to the point that we mistake the map for the territory. Instead of cursing the punk kids, try to learn from them and beat them at their own game.
• BhavdeepSethi 12y ago
  And yet, most coding rounds in interviews are rigorously timed. Almost always, the importance is given to code completeness rather than code design/elegance. I'm sure a lot of talented engineers lose out here.
  • tiglionabbit 12y ago
    Most interviews I've done have expected me to write code on a whiteboard. This is pretty unnatural for me. I'm a very fast typist, so it's frustratingly slow to have to draw letters manually on the whiteboard.
    • akbiggs 12y ago
      At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on the whiteboard without pressing against the time constraints. It's also important to see how reliant people are on their tools.
      • thoughtsimple 12y ago
        Why shouldn't a programmer be reliant on their tools? What a bizarre idea. I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.
        • vertex-four 12y ago
          If you're asking them to design something rather than build something off a pre-existing design, you might like to know that they actually understand the principles of design, and aren't relying on a tool to pretend they do.
• maerF0x0 12y ago
  You have decades on me and I still wish to work your way. It maybe anecdotal, but the more timepressure a codebase has been under the less i've liked it, roughly speaking.
• pzxc 12y ago
  I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is that you are not doing much thinking while you are actually typing, so not being able to type proficiently just means you're slower and that's it. So all else being equal, a programmer that can't type well is a red flag.
  • kenrikm 12y ago
    I would say it's wrong, typing faster will not produce better software. Most of the time involved in writing software is not actually writing it. You may type 3x faster but if he is 5x faster at coming up with a quality solution then your gains will be lost.
    • tuhdo 12y ago
      Think it the other way around: if someone can come up with a solution 5x fater than you and also type 3x faster than you, then how long you are going to catch up with him.
  • georgemcbay 12y ago
    I type about 105 wpm using four fingers (my index fingers and my thumbs); I don't touch type at all but I also don't look at the keyboard, I just know where the keys are from muscle memory (when switching to a keyboard that is unfamiliar to me it takes me a minute or two to adjust if the keys are particularly different in shape/size from ones I usually use). I'm not sure what that says about me as a programmer. In any case I don't think it makes sense to use typing speed as a measure of programming competence because typing speed is never the bottleneck in producing real, useful code.
    • VLM 12y ago
      Things get really weird when you consider the effect of template / tab completion systems like yasnippet in emacs and numerous non-free alternatives. (template systems are an editor extension where you type "i" "f" "tab" and magically an entire if statement stanza instantly appears all perfectly formatted and ready for the details to be filled out.) So if I type at 40 wpm, but 4 keystrokes of mine do more than 16 keystrokes from someone who doesn't use a template system, does that mean I'm effectively typing at 160 wpm? I guess so. I also use an extension that magically aggressively indents so I don't indent, my editor takes care of it for me, so I guess I'm typing at infinite wpm when formatting code, compared to someone who hand indents.
• elwell 12y ago
  > "I’m Glad I’m not a Touch-Typist." Yes, typing speed, when looked at in isolation, does not cause the production of high-quality code. But there is an argument to be made for reducing the friction between one's mind and the code on the screen. Insofar as we can ignore that transference of data from biology to technology, we can think more fully and clearly. So, emacs commands that are fully ingrained in one's subconscious may be good, but probably not the C-u 12 C-x TAB; at least for somebody simple like me.
  • Swizec 12y ago
    The less brain cycles you have to spend on your tools, the more you can spend on your product. :) (I believe in fast typing, usually I'm at some 120wpm, but it does help more with writing than it does with coding)
  • kstenerud 12y ago
    Actually, I've found that the act of moving what's in my mind to a source file is in itself an act of revision for my ideas. I don't need to type fast for it to happen, because I'm not going to write anything at all until I have a solid idea or path in my head. The actual act of typing consumes less than 10% of my programming time, and is for the most part a mere formalization of my thoughts. Would a 50% increase in typing speed make me finish the feature in 4 days instead of 5? Nope.
  • hasenj 12y ago
    I used to believe that. It's why I picked up coffee script. I thought, the less there is to type, the more you can focus on the problem rather than the code. I found out I was wrong. The redundancy actually helps. There's somehow a calming effect in it. I don't know how to put it into words. I found out that I never actually think while typing per se. I have to first jot down my thoughts on paper. Typing out the code becomes almost a mechanical process. I already know what I'm typing, I've figured it all out and put it in paper (or some plain text note in another text editor or note taking app). There's stress in trying to hold it all in your head. That stress is released when you jot things down. Then you can just mechanically write out code with less levels of stress. The explicit syntax means you have more to type but less to think about. I know it sounds paradoxical. But that's been my personal experience.
• JackFr 12y ago
  He makes a reasonable point, but this piece is largely a strawman. And > For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time. is just pure nonsense.
  • thaumaturgy 12y ago
    > but this piece is largely a strawman In what way?
    • JackFr 12y ago
      > As long as everyone makes frequent commits, and doesn’t break anything, everything will come out just fine. He is presenting the arguments and beliefs of his intellectual opponents in a way they probably have not or would not, and then attacking that argument. Now in a piece like this there is nothing wrong with that -- but in terms of the strength of an argument, it is no greater than just enthusiastically stating his preference.
  • benekastah 12y ago
    Re the quote, I agree. Perhaps if I read the study on temporal reverberation I would understand the point, but it just felt like showing off.
  • mattxxx 12y ago
    Yea, the article kinda reads like "bad programmers are bad, and I'm a code master, and the kids don't program like me, and they're bad-bad-bad. their fast is so slow. my slow is so fast." It's weird how he like does this thing where he equates their fast with thoughtlessness, and his slow with actual fast. That being said, I'm all about white-boarding, project planning, and clearing out dependencies, but if an engineer is slowly coding something without any deliverables, chances are their going to hit a wall near the deadline. I've seen this happen too many times.
• leeber 12y ago
  I probably spend just as much or more time sitting, thinking, and staring at partially written code, than I do actually writing the code. It's frustrating when you have superiors who don't understand that time spent thinking is just as productive as time spent typing. That's just my personal style, although I've never worked in "large" teams on a single codebase so can't comment on what styles work best in those situations.
  • mVChr 12y ago
    The best analogy I heard for communicating this to superiors is that programming is like doing a crossword puzzle. 95% of the time you're doing a crossword you're not writing but that doesn't mean you're not intensely working on solving the puzzle.
    • GFK_of_xmaspast 12y ago
      You need to get better at crosswords.
      • mVChr 12y ago
        I'm talking NYTimes Sunday crossword here, not your in-flight magazine.
• cesarbs 12y ago
  > Fast programmers build hacky tools to get around the hacky tools that they built to get around the hacky tools that they built to help them code. This resonates so much with me. Sometimes I worry that I'm falling behind on keeping up with technology, but whenever I try to learn something new it seems like I have to install a package manager, then another package manager inside the first one, then pull a million other tools and libraries and frameworks before I can even begin doing something with this stuff I'm trying to learn. No, thanks. I love computers, I love computing, I love thinking about solving problems using computers, but I hate the direction things seem to be taking. I'm seriously considering a career change in the immediate future because all this crazy tooling truly burns me out.
  • NateDad 12y ago
    Try Go, seriously. There's just the one tool. No package manager, no dependencies... And the code it produces is the same. Just a binary. "Here, have this tool, just run it." It's small, simple, and the community actively searches out simple solutions.
    • cesarbs 12y ago
      That sounds awesome, I'll definitely give it a try.
      • keyle 12y ago
        I am afraid a language change is not going to help your burn feeling
        • NateDad 12y ago
          I don't know that I agree with that. Tooling bloat was specifically mentioned, and Go is quite good with respect to that. There's just the one go tool to install, which can be installed just by unzipping a zip file. From there on in, you don't need any other tools. It just uses VCS for package management. You don't need an IDE... the single go tool has support for pretty much every part of the development cycle - compiling, testing, code formatting, profiling... there are no other tools you need to create real deliverable software. I've been writing Go for over two years and still haven't added any other tools to my standard workflow - git and go are the only two commands I type while writing go code. (At work we use a revision pinning tool, but I haven't needed that on my side projects.)
• wellpast 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. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying is our industry is short on skill sets. With specific skill sets, you can build architecturally sound systems at no extra cost. If I were to build a house today it would take me much longer than someone else because I don't have the necessary skills. I might hurry in which case the house would be shoddy. Is the shoddiness of the house necessarily because I hurried? No. It's because I didn't acquire the required skill sets first. The software industry has no such (practical) concept of the skill sets required to build architecturally sound systems. We have a bunch of well-meaning hackers, and as a result shoddy systems that decay into technical liabilities. Our industry needs to solve this skill set problem. The challenge is that academia has a hard time teaching these skill sets, because they are so removed from the practitioner. And businesses can't teach it b/c it takes years and special experience to actually teach it. So it's not advantageous to a business to teach those skill sets. So how do we do it? And how do we organize an industry around professionals who know how to build architecturally sound systems and code? This is a very difficult problem for a world that has such high demand for code and such little understanding of what the professional skill set would afford them.
  • 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
• monokrome 12y ago
  This is a good article, and the constant need to code bigger bowls of spaghetti faster is definitely a problem. However, I think that it's a stretch to imply that only older engineers do this.
• n3t 12y ago
  Speaking of touch typing, there's a must-read [1] which made me learn and practice this skill. [1] http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret.html http://steve-yegge.blogspot.com/2008/09/programmings-dirties...
  • cesarbs 12y ago
    I usually really enjoy reading Steve's posts, but I have a hard time with this one. Many great programmers admit to being clumsy typers (IIRC Joe Armstrong mentions he's a poor typer in his interview in Coders At Work).
• idibidiart 12y ago
  Has anyone read this book and for those who have is there a correspondence here? http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555 http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/...
  • duncanawoods 12y ago
    I don't think it has a direct correspondence in terms as you might be implying i.e. the fast in this context is mostly still the slow Type II reflective thinking DK refers to. The "fast" coders are making small iterative changes but that doesn't mean the thinking is automatic, just localised and frequent. The deeper analytical and design oriented thinking where someone takes extended time to identify goals, prototype and review different implementations is an important variation of Type II but not really addressed in TFAS. There might be plenty of Type I micro-decisions involved in that process too. I'm pretty interested in how cognitive biases do rear their heads in design problems. I'm scared silly by framing effects where given options A and B, an individual chooses A but adding a third option C and now they would choose B. There are so many decisions that crop up during design/development that are vulnerable to those issues.
• pg_is_a_butt 12y ago
  shut up and code, grandpa.
• kevin_thibedeau 12y ago
  It seems like most of his problems would be alleviated by working on a non-volatile version of the code in a private branch. The kids these days tend to favor a VCS that has this feature.
• paul7986 12y ago
  To all the web agencies who expect jobs (design, code it & WordPress it with custom post types) a mid-size website; 20 to 40 pages) that take 60 hours to be completed in two to three days (pay you for 24 hours of work only) you can go take a flying leap. This industry especially in the web agency world has me burnt out. The agencies all are in competition with each other .. lowering costs and thus expect their people to get things done in manner where their employees have no life but getting their work done. It's exhausting and the work is not very fulfilling. Now I have done the same work at Fortune 500 companies and for someone with a family and who wants a balance work & family/social life that is where you want to be!
• meesterdude 12y ago
  wow, this is great! I definitely have always fallen into the "slow" camp. Though I've always considered it more a matter of being careful and with purpose, and not being haphazard. Quality over quantity. Painting a wall is easy, painting a painting takes much more precision and care, especially when you have to exercise your design skills as a developer. Though often, a lot of the time goes into understanding what it's supposed to be doing in the first place, and from there it's a matter of making it more resilient, isolated and friendlier to work with. I'm the slowest dev on my team, but I squash the bugs that nobody could figure out, or knew were there. Taking things apart takes time and patience, but when you're done you know how it all works and can refactor it to be clearer/simpler, and appropriately comment on what it does and how.
• m0nastic 12y ago
  I hesitate to recommend my process to other people, because I don't think I'm a very good programmer. But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper. This sounds ridiculous (and I can imagine it's not practical for all types of programming), but I've found that it's been tremendously helpful in getting me to understand what all the code that I'm writing does. Most of the code I've written this past year has been in Haskell, so that helps somewhat by not having a lot of syntax to write down, but I'm sure I'd be doing the same thing even if I was writing in Java.
  • beat 12y ago
    Paper is my favorite programming tool. The beauty of paper is that it's easy to find out when you're wrong, when you're pursuing the wrong path, without going deeply in and getting distracted by the small-scale details of the code. This gets right back to the design thing.
    • jschwartzi 12y ago
      To put it another way, it's far less time-consuming to edit a Word document than it is to update an entire production system.
      • beat 12y ago
        No, I need to get away from the computer completely. Word docs (or any other computer typing) is still bound by the computer structure and the computer distractions. With paper, I can draw graphs of relationships, write tables, add notes to things I drew earlier, etc. It's far more expressive, and far faster, than any computer tool I've tried.
  • andy_wrote 12y ago
    I think most people would agree that writing things on paper first is a total necessity if you are writing mathematical code (I mean, are you going to do the equations in your head and type them out?), and I think the benefits to paper increase in proportion with the mathiness. On the non-mathy side, I find it useful to take the concept of "rubber duck" debugging (which is totally applicable to original design and creation, and not just debugging) but write a "duck" document rather than talk out loud. Aside from not looking crazy, I find writing easier for thought organization. Sometimes preparing slides can also be a nice way to really force your thoughts into simplest and clearest form. And hey, when you're done, you can present it to your co-workers.
• aoakenfo 12y ago
  A flurry of hacks tends to beat the "correctly designed" way: http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
  • fsloth 12y ago
    I don't think this describes a "flurry of hacks". To me, the confrontation posed there is not between speed and quality, but which constraints affect the system design most: coherence, or overall simplicity. I would claim the "worse is better" school of design aims to lower overall complexity by cutting the corners where the added complexity to maintain design coherence does not seemingly add any value to the implementation nor the end users.
  • the_why_of_y 12y ago
    "A flurry of hacks" indicates you did not understand worse-is-better: http://www.dreamsongs.com/Files/worse-is-worse.pdf http://www.dreamsongs.com/Files/worse-is-worse.pdf "This advice is corrosive. It warps the minds of youth. It is never a good idea to intentionally aim for anything less than the best, though one might have to compromise in order to succeed"
• wslh 12y ago
  I posted the same article 1 day ago... but used the https address... https://news.ycombinator.com/item?id=8678439 https://news.ycombinator.com/item?id=8678439
  • dang 12y ago
    The dupe detector is left porous on purpose to allow good stories multiple cracks at the bat. A small number of reposts is ok. It's true that who ends up getting the karma on a multiply-posted story is just a roll of the dice. On the other hand, you can stack your long-run odds as high as you want by submitting more and better stories. So it tends to even out in the end.
    • glurgh 12y ago
      You're not really stacking your long-run odds any more than you're stacking your odds by playing the lottery a lot. The odds are stacked in favour of anyone who submits a lot and submits early rather than in favour of someone who submits well.
      • dang 12y ago
        I'm not sure what you mean by submitting "early", or what experience you're drawing on here (your account has submitted zero stories!), but am pretty sure that the odds favour a user who submits a lot that is good [1] and that the latter is where the emphasis should be. We're also working on systems to amplify this effect, so it is going to get more true with time. The point as far as karma goes is not to be attached to any one post, but rather to play for the long run. 1. What counts as good on HN: stories of intellectual substance that many good hackers would find interesting.
        • glurgh 12y ago
          I guess I just found the response "submit more, it evens out in the end" a bit glib (as is, 'your account has submitted zero stories'). I do have some experience submitting stories as well as plenty of just reading and commenting on the site. It seems to me the current system amplifies negative tendencies like being 'first to post' or reposting variants of the same story. I'm perfectly happy to take your word that you're working on something better.
• beat 12y ago
  "There's never time to do it right, but there's always time to do it over". This reminds me of something I've been saying for a while. I'm a practitioner of TDD - Test Driven Development, not Test Driven Design. I like test-first coding not because it's faster, as many proponents claim, but because it's more comfortable and thoughtful. It forces me to slow down and think about what I'm actually doing. I don't think I'm any faster when I'm coding to tests. I do, however, feel much safer. I hate that feeling of cranking out a bunch of code, then it breaks, and I don't know what broke or why. But good design is absolutely not an emergent property of the process of coding! Thoughtless coding leads to poorly structured spaghetti. Well-tested spaghetti is still spaghetti! Good design is always a matter of compromises. You can either make those compromises in a conscious and thoughtful way, or you can close your eyes and hope for the best. Good luck with that.
  • diltonm 12y ago
    >> But good design is absolutely not an emergent property of the process of coding! >> Good design is always a matter of compromises. You need to have coded something to have shined the flashlight into the darkness so you can put a few dots on the wall and start envisioning a path. I have small scrap projects to let me shine the light and see what reflects back.
• angersock 12y ago
  I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) that manically hop from framework to framework and sprint to sprint because design work is "too slow" end up expending more energy than if they'd just been lazy and really thought about what they wanted to accomplish before they worked on it. This is especially true in business, where that mindset is invaluable for skipping work you'd otherwise do while finding fit. Second, I disagree that on a good team engineers aren't fungible: the fact is that, if you have one person who "owns" a part of the code, you are inviting disaster and bad design. This, and not its converse, has been proven to me over and over the last decade. Sure, one person might have the domain expertise or familiarity with something to really nail it, but they should never be the only one on the team who can do so. If they are, you slip them pizzas under the door, make them happy and productive, and then sack them as soon as you can extract their knowledge for they are a liability waiting to turn into a problem. Third, and perhaps most controversially, the author supposes that good design is important. For almost any business, sadly, it isn't. Nobody gives a shit when you have deadlines to meet and bills to pay--and if you're lucky, you can push that burden up onto the next poor bastard to inherit the codebase after you've cashed out. I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed (and cleverly stood back up, but not because the majority knew or cared about design).
  • EdSharkey 12y ago
    But NextSTEP didn't fail. It succeeded, in the biggest, most spectacular way I can imagine an operating system would. So, design does matter. Design seems to matter a great deal at Apple, so that backs up your other point that most other businesses could care less about their software's design and that NextSTEP at Apple is an exception.
    • 12y ago
• chillingeffect 12y ago
  Great intent, but modulating speed is only one of several important vectors toward good code architecture. I would add planning out on paper, in (small) groups. Also, reviewing designs, objects, protocols, schema, etc., before writing code. The author mentions thinking while gardening, but that doesn't share with others. Also, planning for the future, for maintenance, debugability, verification, validation, for re-use, for modularity, for upgraded hardware and in some cases regulatory, etc. And developing documentation before, during and after coding. So yeah, sneaky trick to get us all to talk about our best practices by hyperfocusing on speed :)
• atjoslin 12y ago
  My thoughts on this article: "Yes, new software and new businesses need to grow. But to be sustainable, they need to grow slowly and with loving care. Like good wine. Like a baby." Why can't I grow quickly "and with loving care"? :-)
• Arzh 12y ago
  > And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films There is really one design process with all of the great cathedrals, railroads and films. One person is designing and running the show. It really just reads like this guys doesn't like to work with people who like to work by committing a lot. I work with a programmer that is in his late 50s and he likes to work as the writer does. I can get his same level of results with my method, which is much 'faster.' It's not that I am much smarter than him we just have different ways of doing it and we get the same success rate.
• sytelus 12y ago
  It's not about being fast or slow but being in a flow. You don't want to go faster than you can or intently slow down. Unnecessarily long design cycles inhibits experimentation and may cause you to loose touch with reality. Artificial push for speed up is probably even more harmful. So I would vote for "flow movement".
• tobyc 12y ago
  I definitely see the value in taking the time to design things correctly and making sure you're evaluating all angles — I'm not sure if it's 100% necessary to say that to do that you always need to be slow though. I think the difference between a fast programmer and a slow programmer often isn't that the slow one is methodically designing and making everything perfect, it's that the slow one has so many more inefficiencies in their workflow. A good and fast programmer generally knows their tools inside and out, and they're willing to learn new tools when they need to (and not dismiss them because their current setup works good enough and it's what they know). Speed isn't an indicator of good or bad quality. I would say that both mastery and improvement of tool is more of an indicator.
• larrys 12y ago
  "I’m Glad I’m not a Touch-Typist." Have to disagree with this 100%. A touch typist can always hunt and peck if they want to or need to for some reason (would love to have a reason for this being a benefit though). Being able to touch type helps greatly with just about everything when you are using a keyboard. Sending emails, writing letters, filling out forms, coding, the command line and so on. Not only that but it's extremely easy for the average person to learn to touch type (I learned from a book and was proficient after about 3 week). I really can't think of a good reason (other than taking the time to learn which as mentioned is easy enough) to not learn to touch type. I think it's one of the least talked about productivity boosts out there.
  • KedarMhaswade 12y ago
    +1. I am a bit sad that the author chose to downplay the (usefulness of) touch typing.
  • einhverfr 12y ago
    I agree but the concentration that comes with slowing down thoughts is also a very valuable skill. I suggest learning to write with a quill pen, or at least a dip fountain pen. Coincidentally many of the better coders I have known have valued dip fountain pens.....
• donatj 12y ago
  I was once a "fast" developer, like thousands of lines a day. I could knock things out at an amazing pace but they always had problems and were rarely testable. That actually worked out OK where I was where we basically built things and ideally never touched them again. Now, 8 years later I write maybe 50-100 lines a day. I can see all the vectors of things that would go wrong and take the time to mitigate them. I work with "hotshot" young developers who write my old maybe a thousand+ a day. I'm the grumbly old man in code reviews who forces them to break them into multiple smaller pull requests. The difference is my 100 lines will stay in the codebase for years, whereas their thousand will likely be rewritten several times over in the lifetime of my code. There's tradeoffs here, to be certain. I see so many younger devs thinking just because their code is tested that its "good". This is certainly not the case. There is so often so little consideration of how their code fits into the "big picture". We end up with 5+ "widgets" where one general widget would have sufficed if they'd thought things out ahead of time. Sigh. Shakes Fist. Get off my lawn. Old man grumbles... I'm 28.
  • Raphmedia 12y ago
    Hotshot here. Oh, how I wish I could slow down. But how could I? My task must be done in time for the sprint. Everything I do must be logged into the right ticket, I need to time everything I do. The enemy is time, and I must defeat it. I wish I could output better quality code. Right now, I'm working on a project that was finished at 90% and I need to finish it. The code is horrible, but I have no time to fix it. So I'm simply going to hack at it as fast as I can and make my agile manager happy.
    • donatj 12y ago
      - Well it sounds silly but there will be fewer tickets when you slow down. - If you work for a company where you're not free to question the legitimacy of tickets, get out now. - Not all tickets should need to be done by the end of the sprint, but rather what can be done well or what legitimately NEEDs to be done for buisness reasons. I know your manager mught say everything needs to be done but that is a bold face lie. - If you're throwing together garbage just to get the tickets done by the end of the sprint you are doing Agile wrong and just building technical debt rather than a product.
• mattxxx 12y ago
  I'm all for programming slowly, but how many pieces of code are built slowly, and, in the end, turn out to be built wrong or cumbersomely? It seems like, if you write slowly, you gotta have legitimate deliverables and tests at every step.
  • shizzy0 12y ago
    Excuse me, are you asking for data? for evidence? We're here to assert our opinions, speculate on what's best, and cite an anecdote—sadly.
• Spearchucker 12y ago
  This guy speaks to my soul. A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky. So the dev team just started hacking it out, field by field, and saving the whole form into Mongo as a single, nested document. Guidance was hard-coded into the HTML. It was fast, and at the start everyone was awed. Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off. All because agile. In my 20's I'd have been emotionally destroyed. Ego like an aeroplane into the side of a mountain. No survivors, call of the search. Happily I'm in my mid-40's. I know better, and I know better than challenging an inexperienced project lead that has too much authority. So I move on. There's always a project that's more suited to my style of work (slow).
  • michaelochurch 12y ago
    The term "agile" deserves a preceding apostrophe, as in 'agile, because there are two letters (the 'f' and the 'r') being trimmed. I fucking hate that nonsense. It's a total scam.
    • einhverfr 12y ago
      Obligatory cite to SQL On Rails http://sqlonrails.org/ http://sqlonrails.org/
    • spacemanmatt 12y ago
• jaunkst 12y ago
  Speed, is a constant demand. The rate that we are creating new frameworks, languages and platforms is an all time high. We toss them away as quick as we build them, by the time its reaching mainstream adoption we are refactoring the core, and expecting developers to adopt the changes before they master the first mature iteration. Born to die software is here and its going to cause a massive fracturing. If we adopt reverse compatiblity maybe we can offset the repercussions. I expect my code to start to deprecate in atleast 6 months in some manner.
• EdSharkey 12y ago
  Lack of design in software nowadays was cited as a problem in the post. I agree, and I think there's a lot of not-classically educated hands out there that wouldn't know a good design document from bad. Nor would they have any practical knowledge of a combination of: how to structure code in large code bases, test their code, converse about/apply software patterns, document their API's for public consumption, RAII, SOLID, TDD, etc. So, I think there's little hope for improvement in software quality/design/success metrics/etc. Big up-front design only satisfies document weight tests and typically does not stay up to date with the software. So, just simply saying "we need more design" is not going to get us anywhere but hell. Self-documenting code is a nice idea, but scales only so much in a large codebase. UML is a bear to produce and maintain, and I only really like it in whiteboard discussions, not actually drawn in a tool. Wikis devolve into a mess of disconnected ideas. Successful teams I've been on tend to rally and organize designs around the already generated documentation (like JSDoc or JavaDoc), but those docs often only focus on the user-facing API's and leave the internals as a partially documented wasteland. A few teams I've been on had a scribe, which was sweet, but not usually. What patterns of design and documentation actually work well for you in real-world, large project/team scenarios? Regarding needing an aged "adult in the room" to guide the fledgling developers to glory, as I think the OP suggests is an answer to the problems ... Well, in my many experiences where imparting wisdom from on-high was the goal, that has been a miserable failure. It was all because said "senior architect" or whatever the title was invariably only cared about blessing random big decisions randomly/destructively and had otherwise checked out to walk his dog after lunch and otherwise coast during his pre-retirement. All I can say is, God bless 'em. I do NOT count on age as a factor, only that a developer has reached a certain point of experience in their career. What I DO count on is one person who can enforce a clear vision with passion. Who holds the torch for your team? Is their grip shaky or firm? Where are we headed? Are we headed there with conviction? Does the end goal still seem plausible to all hands after every step we take? If you have proven you've got the chops and can back up all your assertions with creditable past successes and/or literature, you can rule your team and demand excellence - YOUR excellence! Pick a darn direction and let's go! I have total respect for that someone that has a coherent vision AND can communicate it. Agile methodologies sound plausible to address design and software productivity issues, but I have yet to see exceptional results from an agile project vs waterfall. This is probably just because software is a hard thing to do well in any case, and is subject to political winds, funding, ineffective product owner, etc.
• edpichler 12y ago
  Really liked this part: " And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films."
  • GFK_of_xmaspast 12y ago
    Historically, cathedrals might stand unfinished for decades at a time. Also the early days railroads were famous for brutally exploiting labor in order to get built as soon as possible. Haven't you heard of John Henry?
    • edpichler 12y ago
      I haven't heard of him. I did not understand you. It seems you believe there isn't collaboration to build cathedrals, railroads, and feature-length films.
      • GFK_of_xmaspast 12y ago
        Of course not. What I'm saying is that these are very much not examples of well-run projects that aren't exploitative of labor.
• lifeisstillgood 12y ago
  Thank god - there are others out there speaking my language. The ideas of dysrythmia are spot on. Totally fantastic - an insight well put. Thank you
• aabeshou 12y ago
  What's with describing his friend as a "mature, female software engineer"? That strike anyone else as weird?
• overgard 12y ago
  I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course, the corollary is that I usually do these things on a branch so I'm not inflicting it on my coworkers) The problem with doing a big design up front is that you're generally going to run into something that's surprising, that you didn't account for (unless what you're doing isn't novel -- but then, why are you writing code rather than reusing it?) I think when people get all ponderous about these things, they're not really learning about the problem, they're just procrastinating. We're not building bridges here, if your first attempt isn't brilliant you're not out a million dollars of concrete.
  • cgearhart 12y ago
    It depends a lot on the problem domain. Sometimes rapid prototyping is a useful tool, but the benefits rapidly diminish in the face of complexity. In my experience with moderately complicated scientific and mathematical software, there isn't anything to prototype - either it works, or it doesn't. If you aren't deliberate about design choices, the bugs can be really devious to find and squash.
    • overgard 12y ago
      I think the implication of this article is that fast = reckless, but I disagree with that. Sometimes you recognize that you need more data points, and writing something that works will move you closer to the correct solution, even if the first version isn't perfect. But yeah, it depends on the problem domain. If you're asking me how to build a website, I can probably have a pretty solid idea of what that code should look like. It's not a novel problem, usually. If you're asking me to build, I don't know, a voxel renderer and you're trying to figure out if an octree is the right way to go for representing the data, or you need to do something more exotic, I'm gonna have to play around a bit.
  • snowwindwaves 12y ago
• 4ydx 12y ago
  This is why golang.
• seanconaty 12y ago
  I like iterative development but I also really like the author's "cauldron of soup" metaphor. I've definitely worked on projects where I feel like I'm rebasing/updating more than I'm actually doing work to add any type of new value.
• err4nt 12y ago
  > My wife often comes out into the yard and asks me: “are you coding?” Often my answer is “yes”. I think I need this quote in my kitchen! My girlfriend often pounces be with the accusation "YOU'RE NOT WORKING" if she sees me out of my chair moving around, doing mindless house chores or half-vacantly tossing a cat toy around the house, or running errands, but the reality of _design_ is that it happens all day. And when you're done 'work' for the day, ideas and solutions still happen. I'm working in the shower, I'm working all evening. I'm working waiting for the bus. I can either let it pass or write it down, but I can't seem to shut it off. But I don't mind. I've been learning to slow down too. I used to be a perfectionist and when I was billing a client I would only bill my butt-in-chair-and-head-down time as billable hours, but lately I realize if I sit and think, plan, and research for 2-4 hours, and spend 2-4 hours implementing the results of that thinking, I get more done each day than 8 hours of butt-in-chair-head-down typing. They key is to approach it as design, and that's where my training as a graphic designer comes in handy. The Design Process was drilled into out heads and I've only recently been applying it to my coding :)
  • diltonm 12y ago
    I suspect she knows when you have that stare like you're solving a puzzle while playing with the cat's toy.
  • a_e_k 12y ago
    "Sunday: Lay on my back most of the day, reading, sleeping and day-dreaming. Very literary. Some women, however, resent it, so young writers should choose their wives with care. Many a promising career has been wrecked by marrying the wrong sort of woman. The right sort of woman can distinguish between Creative Lassitude and plain shiftlessness." -- Robertson Davies "The Writers Week" (1959)
  • elwell 12y ago
    Bill by the day, or by project.
• oldpond 12y ago
  One of the key points in the article is that the OP had lots of experience with Bay area startups. This could be part of their culture. If you use agile you can achieve a code velocity a touch higher than standard, and if you really want to push the limits you can. I agree, however, that good design takes time. I was at a conference in Sweden last year, and the conference App was a bit problematic. The poor dev team was chained to their keyboards right in the middle of the breakout area trying to fix it in real time. I felt like saying, "Guys, it failed, go enjoy the conference." My experience lately in "normal" shops (non startup) is that the skills sets are just plain missing. It's hard to find anyone that can code at all, let alone code fast. Good post. Thanks for this.
• markbnj 12y ago
  Also in the largely-agreed camp, and probably unsurprisingly I'm about the same age. But unlike some I don't have a problem with the word "slow." Yeah, it has negative connotations, but it's clearly meant as an ironic counterpoint to the culture of speed. Whatever, as long as it will get the young guys I work with to figure out what the problem is before trying out a solution, I'll be happy.
• pauldprice 12y ago
  Glad he doesn't touch type? What a lame excuse for not mastering the tools of his trade! That's like a carpenter saying he's glad he never properly learned to use a hammer. There is a time and place for a steady pace and thorough design process, but not in the early stages of a startup. If you can't keep up with your user's feedback and market demands then you'll lose to a scrappy team that can, no matter how beautiful and elegant your code. 95% of software startups that become wildly successful were built on an initial base of excrutiatingly ugly code. Gold plating code for a business that is bound to change directions is a great way to ensure failure.
  • shizzy0 12y ago
    Yeah, who needs entering code to be a challenging "mini-game" instead of an automatic, non-thinking skill of typing?
• danenania 12y ago
  While it's true that most nontechnical managers over-prioritize speed and underestimate the dangers of technical debt, it's also true that many otherwise great engineers are inclined toward premature optimization and tend to lose track of business goals. In most contexts, an engineer that understands both when solid, thoughtful, slow engineering is appropriate and when it's NOT is worth immeasurably more than an engineer whose only gear is extreme rigor.
• chandankumar 12y ago
  IMHO, writing a good program goes through lot of thought process. You keep thinking about the solution of same problem till you get the best solution (or at least you are satisfied with it). So it is going to take some time. But I guess after having some experience, you will find a way to create well designed code more quickly than before.
• realrocker 12y ago
  Only few businesses want a well-crafted software. Today's startups are endeavors of treasure hunts. You build a ship just good enough to hit the island. If it doesn't work out(which in all probability it won't) you dump the ship. If it does, you still dump the ship. There is a element of expected failure in the current enterprise of writing software which calls for and pushes people to knowingly write bad fast software. As the author says it will be faster to write slowly if the goal is to write good software. But the goal is rarely that.
• cxseven 12y ago
  John Draper, AKA Cap'n Crunch, made a great case for it: "It was a perfect coding environment, coding in jail. [...] Those long nights without the computer really got my smarts in top gear, as I really focused in getting the code perfect and bug free. Not having a computer some of the time, got me to thinking more about writing good code, and less time debugging. During this time, I wrote a really cool FORTH debugger that allowed single stepping through FORTH code (Totally unheard of in those days). I also write a De-compiler that would take the compiled FORTH code and re-generate source code. This was invaluable in tracing down some gnarly compiler problems in FORTH. You see, I was not only writing a word processor, but I was also developing the language on the fly as well. Modifying the compiler, interpreter, and I even write a DOS (In forth) to manage the easyWriter text files, because EasyWriter didn't need DOS. So I implemented one, using a FAT (File allocation table) and all that other Gnarly Disk Operating system low level code. I found out that FORTH allowed me total flexibility. If the language didn't have a feature, I implemented it. Simple as that. The day finally came when I was to be released from jail, and Matt had already rented a fully furnished apartment in West Berkeley for me, and met me at the jail when I was released. That evening, we met at the IHOP on University Ave to sign the contract YAY!! and the incorporation papers YAY! Now we can call ourselves Cap'n Software Inc. We rented office space on Telegraph avenue a block from the UC Berkeley campus and called it our "Corporate Headquarters". Soon we got our first royalty check of $3500, and I gave Matt $1000 of it and put him on a salary. Michelle, Matt's roommate and holistic friend was hired on as our Secretary, and handled all of our bookkeeping. WOW!! I get out of jail and in 24 hours, am president of my very own software company. SUPER COOL!!" http://www.webcrunchers.com/crunch/Play/ibmstory/ http://www.webcrunchers.com/crunch/Play/ibmstory/
• lyudmil 12y ago
  In general I think there is a case to be made for "slow" programming, but this article falls short for me. I happen to think that software development is a knowable discipline, that we're in the process of figuring out how to build the kinds of systems we need and struggling with a new kind of engineering where there are no physical constraints. Therefore, I think we have a lot of exploring to do in order to come up with practices that reliably lead to better software and certainly the speed of the development process and the number of iterations is an important thing to experiment with. However, the post is too wishy-washy to teach anything meaningful. What does "dot my i's and cross my t's" mean in the context of software development? What does "something like implementation-ready code" mean and why is it useful? How do I, as a person separate from the OP, get from where I am today as a developer to the super effective zen-master you're telling me I could be? I'd love to read that post, because the one I just read makes it seem like I should wait to get older and take up gardening.
• dschiptsov 12y ago
  > You can’t wish away Design Process. Furious activity is no substitute for understanding. Before you start to writing the code, YOU HAVE SPEND A LOT OF TIME STUDYING YOUR PROBLEM. (Brian Harvey, CS61A) If you can’t write it down in English, you can’t code it. Programs must be written for people to read, and only incidentally for machines to execute. Immortal classic.) The sooner you start to code, the longer the program will take. Details count. (Devil is in the details). Get your data structures correct first, and the rest of the program will write itself. (Data structures suggest algorithms). Premature optimization it the root of all evil. There is nothing new, of course. In "old times", even if "old programmers" didn't have such marvels like Java or Javascript, being mostly scientists, they have figured out "how their minds work" and in what kind of processes they are mere parts. An one sentence summary could go like this - "Programming is an engineering discipline, Coding is a translation skill". To write down quickly one has to spent a life-time thinking and doing.
  • aercolino 12y ago
    Yes, someone in another thread is discussing about skill sets to be learned to engineer software, but I think academy already does a decent job. To engineer a good architecture you need time to thoroughly think and explore alternatives. Coupled with deep field knowledge and an even deeper know how, gained by means of experience. And to build the best is impossible by definition: you can only hope to build a better one. I didn't know what a fast programmer was until I had to work with one. The king of copy and paste. All his neurons on his fingertips. He showed to me that thinking with their hands wasn't limited to manual workers. Luckily for me, his awesome speed allowed me to become his "boss" a couple of months after being hired. And I'm not being sarcastic here. The manager saw he was better left typing and me better left thinking.
    • dschiptsov 12y ago
      That's why, perhaps, in pre-Java era, in good schools they taught "big ideas in CS" instead of Java syntax and how to OO everything. Algorithms, Data Structures and reasoning behind them, Scheme courses of CS basics (based on SICP) and Operating Systems, so a student could understand the principles and design decisions. Then such student could code in any language, because syntax and common idioms are much less important than appropriate data structures and processes. Then, perhaps, they will use a modern file-system as a database (like this very site back-end does) instead of bullshitting each other about what re-implementation of optimized in-kernel routines in Java is more popular, etc. I know syntax of about dozen languages, but I am inferior programmer due to lack of appropriate theoretical background. I could spent days trying to figure out, should a request be a closure or an assoc or this fancy but costly "persistent-map", and these nuances like aliasing and locality in Clojure and CL. Of course, one could always Ctrl-C/Ctrl-V from millions of online tutorials and "get shit done", but I cannot write anything without understanding why this instead of that, not because they say so in some narcissistic, over-confident blog-post. Thank god programming is my hobby, not my job. So, it is not about syntax or how pointers were arranged (in structures and ADTs or in classes and objects) it is about whats and whys instead of hows. Coding is easy. Programming is difficult.
• msolujic 12y ago
  here is one little pearl The sooner you start to code, the longer the program will take. Roy Carlson Anon. University of Wisconsin Taken from BUMPER-STICKER CS http://www.bowdoin.edu/~ltoma/teaching/cs340/spring05/coursestuff/Bentley_BumperSticker.pdf http://www.bowdoin.edu/~ltoma/teaching/cs340/spring05/course...
• dansingerman 12y ago
  You get shitty fast programmers and shitty slow programmers. You get good fast programmers and good slow programmers too. 'Fast' or 'slow' in isolation are not really a measure of anything valuable, except perhaps how an individual fits into the team culture. The crucial thing to measure is how long it takes to get to good, robust software that does what it needs to do. There are many strategies to achieve that (agile or big design up front or others) but software engineering as a medium is too immature to have found the one true way (maybe there will never be a one true way). Up front design and emergent design have both succeeded and failed on many occasions. This post reads to me as someone who doesn't like working with younger teams as the work style often doesn't fit, and therefore concludes the team's working style is wrong, rather than he just subjectively doesn't like it. Most of this thread sounds the same to me too. Maybe the benefit of a fast programmer is it is quicker to find out if they are shitty? I'm 42 and consider myself fast-ish FWIW.
  • hawleyal 12y ago
    Agreed. I am fast, but refactor constantly, so there really is no "final" code or "finished" result. The current form is continously honed and refined. My cycles are very quick, however the design is not rushed but rather well thought out over many iterations.
• crispweed 12y ago
  'Slow programming' has too many syllables, and you end up having to say it fast. Let's call it slooowgramming.
• keithnoizu 12y ago
  The Author lost me at "I'm glad I'm not a touch typist". Coding isn't about typing at the same time when programming you should be writing code not thinking about where the semicolon is. I type and interact with my IDE incredibly rapidly. Generally my ability to type quickly is not the bottle neck. Sometimes it is. When it is I'm glad I can do it as rapidly as I can. Meanwhile I agree with other comments that slow programming is the wrong word. You can rapidly write quite a bit of code with out needing to resort to hacking or avoiding best practices. It depends on your familiarity with the space and ability to properly construct the problem in terms of implementation quickly. The point here is that you work at the appropriate pace and put some sense of craftsmanship into your work. I doubt that over the course of a sizeable project the approach of being diligent versus hasty is going to result in the diligent programmer tacking longer to get the same amount of work done.
• jroseattle 12y ago
  IMHO.... This can be appropriate in certain scenarios. It royally sucks for other scenarios, though. Measure-twice, cut-once is a great development strategy. However, iterative-fast can have as many benefits as slow-and-steady. Are you certain about your feature set? Must the feature be everything we can imagine when it's released for the very first time? Are there umpteen other things that also need to be addressed in the allotted amount of time? Are you sure you're not over-engineering a solution? The biggest issue with slow-and-steady: cost and time-to-market. Of course one can argue "but cost is actually lower" and "time-to-market for a solid product will be the same or less", but (for me) that equates to any iteration having zero value along the way. And for us, that's just not true. I'm default-wired to well-thought systems and architecturally sound operations. I would certainly like to deep-dive into our codebase and bring it to a beautiful state of robustful bliss. The only problem is -- I can't afford it right now. Maybe later, but early in our lifecycle, speed is more valuable.
• talles 12y ago
  He uses a picture from here in the article: http://designapplause.com/2012/infographics-the-variables-within-design-process/31329/ http://designapplause.com/2012/infographics-the-variables-wi... It's such a beautiful infographic, but I couldn't interpret it... anyone knows it those are based on real data?
• GFK_of_xmaspast 12y ago
  I've worked with slow programmers, including someone a lot like the poster, and in my experience they never produce anything that was worth the wait.
• bko 12y ago
  This article reminded me of something I read in the Vanity Fair article about Sergey Aleynikov, the Goldman programmer[0]. >He’d been surprised to find that in at least one way he fit in: more than half the programmers at Goldman were Russians. Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: they had been forced to learn programming without the luxury of endless computer time. “In Russia, time on the computer was measured in minutes,” he says. “When you write a program, you are given a tiny time slot to make it work. Consequently we learned to write the code in a way that minimized the amount of debugging. And so you had to think about it a lot before you committed it to paper. . . . The ready availability of computer time creates this mode of working where you just have an idea and type it and maybe erase it 10 times. Good Russian programmers, they tend to have had that one experience at some time in the past: the experience of limited access to computer time.” Even while he was in prison he managed to code: > A few months into Serge’s jail term Masha received a thick envelope from him. It contained roughly a hundred pages covered on both sides in Serge’s meticulous eight-point script. It was computer code—a solution to some high-frequency-trading problem. Serge was afraid if the guards found it they would deem it suspicious, and confiscate it. That kind of discipline and meticulous thought is very hard to build in to someone who has never had these kinds of constraints but it is certainly an admirable goal. [0] http://www.vanityfair.com/business/2013/09/michael-lewis-goldman-sachs-programmer http://www.vanityfair.com/business/2013/09/michael-lewis-gol...
  • logicalmind 12y ago
    This is a good point. I am not Russian but I learned programming in the same way because I started out doing embedded work. Where a build/deploy/test cycle could take hours to an emulator and debugging was very unfriendly. If you did not do rigorous thinking about your program and what you were doing, you could waste huge amounts of time. I no longer do embedded work, but the mentality has stuck. When I commit my work, it tends to have fewer bugs than what my co-workers produce.
• UK-AL 12y ago
  The main issue are not the developers. In my experience its the pressure the company puts developers under. Most developers would love to take time develop well designed software. But most companies push, push, push for more features in x time. The first thing that gets cut is design discusion and the ability to go back and improve old code. The older the developer, the harder they are to push around(They've seen it all before, probably been a manager before) and probably why we have a agist industry because companies like developers they are easy to manipulate.
• benihana 12y ago
  >This is why I believe that we need older people, women, educators, and artists Remember, if you're a young man, or you don't have the title of artist or educator, you're obviously not a people person and you're fucking up software, shitlord.
• ncphillips 12y ago
  This is exactly how I work. It can seem a slower when you tell your boss you just scraped everything to start over, but it's actually super efficient. It never takes nearly as long to rewrite an application. On my latest proejct for example, I took 1 week to think about the problem and play around with different data schemas, then I spent 3 weeks writing the program. It worked well enough, but there were a lot of holes, and it was a god damn mess to read. I rewrote the entire project in two days. That's right, what took me 3 weeks of playing around only took me 2 days the second time around, and it was well worth the effort. The refactoring increased security tremendously, and made many parts of the code so much cleaner and readable it brings a tear to my eye. What's even more important is that I was able to easily add new functionality which would have taken a lot of effort to implement because of the way things were written before. Had I left things the way they were, or tried to refactor without a complete rewrite, I would have just introduced more bugs and got really frustrated.
• bitwize 12y ago
  Here are my Reddit comments on this story: I've always programmed thus: * Try to assimilate a mental model of the bit I'm working on, and as much of that bit's dependencies as is practical, into my head. This may involve fiddling with the code and seeing how it breaks when I do certain things to it, or hammering at it inside a REPL or similar. The bit that I'm concerned about could be a single method, but is usually larger. * Try to develop a mental model of the bit as it _should_ be. Do a diff between the 'is' and 'ought', make code changes as necessary, fiddle with the new code to make sure the shape of its function is roughly the 'ought' shape. * Update the unit tests with specific tests for the 'ought' case, run tests, fix failures. * Check in or submit code for review. This is not how software is written now. How software is written now is a hill-climbing algorithm where each cycle is one "red-green-refactor" sequence. Write a tiny failing test which no matter how small or trivial still has a few lines of setup/teardown boilerplate, make the smallest possible code change to make the tiny test pass (change minus sign to plus sign?), run the ENTIRE test suite to make sure that your sign flip didn't break anything anywhere else, if the code needs to be refactored do so and run the entire test suite again, fucking repeat. There are a number of theoretical advantages to this from a management perspective: * Developers produce working code quickly in the early stages of the lifecycle, whereas with the slow approach you do a lot of sittin' and thinkin' up front without much to show for it -- maybe some design documents or UI mockups, I dunno. * Development no longer relies on developers' internal mental models of the code. Developers now code against a model which is incarnate in the test suite -- itself a deliverable, documentable artifact. * Because programmers no longer work from internal mental models but the single-bit state of "do the tests as written pass or fail?", the concept of "code ownership" -- along with related management problems of coders waxing territorial over the pet modules they've spent days or weeks ruminating over in order to understand deeply enough to change -- evaporates. * Programmers look busy all the time, because they are constantly typing out test code to exercise even the most trivial of changes. * Thanks to pair programming, you no longer need worry about the "guy in a room" problem. Your dev team is always seen to be interacting with one another. But I hate it because it is incompatible with my temperament. I like to think about _what_ it is I intend to write, before hammering out test cases to exercise it.
  • pandler 12y ago
• ThomaszKrueger 12y ago
  A lot depends on who you are programming for. Usually it is for a company that places more importance on a deadline than anything else, including quality. Other "ilities" are even less relevant. So you just hunker down, and produces something that "works" very fast. For, say, a small dataset. Then either the project finishes (abandoned sometimes), or it grows (exponentially sometimes), and what was created fast no longer is usable. So you do it once again, now to support the new requirements. And so on. We are constantly rewriting systems, as we continuously copy data from different media. It keeps us employed. It is much easier to be remembered for doing something fast than for creating something that lasts.
• afar 12y ago
  I wonder what pg thinks of this?
• Mobiu5 12y ago
  Bruce Lee say: Code like water ^_^
• kendallpark 12y ago
  I feel like "agile" has come to mean "get shit done fast" in today's programmer culture. But just as "agility" and "speed" are not the same, agile development does not necessitate a race to the finish and similarly is not the antithesis of the slow programming style (as some commenters seem to be suggesting). I think people have wrongly used agile as an excuse to implement first, reflect later, refactor never. In the original agile movement, there is a lot of time devoted to refactoring. You hack something together that accomplishes your goal. You get to see how it's working, get user testing up and running, and then reflect. But underneath the hood the program is a complete mess. This is the time for an agile developer to go back and majorly refactor the program into a neat, well-organized system. Maybe even rewrite. The problem is people on the business side of things see a near-complete project that they want to launch ASAP. It may even feel that way to the developers. I think the refactor part of the process gets cut short because of the desire to push the product out the door or work on new feature sets. You're only doing half the agile process in this case. I'm definitely not in the "plan first, build later" vein of thought. It's not how I program or do artwork (I'm a hobby artist as well). I need time to play around and experiment with different ideas in real-life implementations before settling on my plan of attack. There are so many ideas that may seem great in your head, but don't do well IRL. Additionally, you may stumble upon a new idea in the process of experimenting. The thing I long for the most as a programmer is more time to refactor. Time to refine my code. There is something to be said about craftsmanship as opposed to mere production. One thing I've enjoyed about my own personal programming projects outside of work is that I have time to sit back and reflect. Is this the best way of modeling X? Is there a more simple way of expressing X? And then I can do major refactors/rewrites that would never fit into a sprint at my workplace. But I do believe the investment will pay off in the future when it comes to maintenance. And extra day refactoring now could save weeks of debugging later on.
• scelerat 12y ago
  One of the first things I learned about programming was to write the problem down on paper. Diagram it. Don't even start coding until you have a good map of where you're going, at least at couple levels of detail. Most of the problems I've encountered myself or seen with others is directly related to coding too soon.
• kentpalmer 12y ago
  Software Craftsmanship Vision See http://kp0.me/SoftCraft http://kp0.me/SoftCraft The problem is that Software is in fact a new kind of object, i.e. it has a different ontology from most other objects which is defined by what is called Hyper Being by Merleau-Ponty and Differance by Derrida. This is in contradistinction to most objects which are either Pure Being (present-at-hand) or Process Being (ready-to-hand). Hyper Being objects are defined by Derrida in terms of differing and deferring, but we can talk about instead decoherence and delocalization of Software. Delocalization has to do with the fact that design elements are spread out within programs and in spite of object oriented design are not self-contained at the program level. Decoherence has to do with the fact that programs lack internal coherence intrinsically due to the nature of general purpose programming languages and their multi-paradigm nature and the solution to this is aspect oriented programming which attempts to render coherent elements that are non-localizable. But neither aspect oriented programming nor object oriented programming completely solve the problem of the intrinsic quantum like properties that occur in software. Software designs are like classical physics in relation to the quantum like nature of software. See my original paper on this called Software Ontology at http://kp0.me/SoftOntos http://kp0.me/SoftOntos. There are in fact various ontological levels identified in Continental Philosophy and beyond Hyper Being is Wild Being and Ultra Being which both have implications for our understanding of Software. Also I don't see any reference to Fast and Slow Thinking by Daniel Kahneman. There is some basis for understanding the difference between Fast Thinking and Slow Thinking in his work. Fast Thinking makes up narratives on the fly while Slow Thinking creates arguments more ponderously. Actually in Software Craftsmanship we need both and we need to balance these two forces in the patterning of our development processes. Kent Palmer http://kdp.me http://kdp.me
• ThinkBeat 12y ago
  I think it is sad that so much of the discussion here is about the name. The focus is upon marketing not on the substance of the article / blog post.
• lonelybug 12y ago
  I don't understand why so many software developers/engineers believe engineering without design is a good practice. Maybe you should read this article http://martinfowler.com/articles/designDead.html http://martinfowler.com/articles/designDead.html. Martin fowler is one of the people draft the manifesto for agile software development. If you still call yourself software engineer, then, remember agile != no design.