Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Duct Tape Programmer

joelonsoftware.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: The Duct Tape Programmer

#41

Post by tsotha »

collyw wrote: post #40
dilap wrote: post #7

Earlier quoted context omitted.

I feel for ya. People often rail against reinventing the wheel, but 36 times out of 37, I'd rather have an in-house created wheel that rolls how we know it should with code we understand than some 3rd party bag of voodoo that supposedly roles in the desired ways, maybe.

I would far rather have something put together with well known, documented, tested third party libraries than some undocumented in house crap that one "superstar" developer knows how to work and no one else.

You think that, but in my experience the "well know, documented, tested third party libraries" try to be all things to all people. So when you just need something to cut your steak with what you get is a Swiss army knife with twenty different blades of which you can identify three without spending a week poring through documentation.

Instead of just looking at fifty lines of code to see what the "undocumented in house crap" is doing, you'll be spending all your time on stackoverflow trying to figure out why these third party libraries don't play well together. "Has anyone had this problem with version 3.3.2 of JLSHE and version 8.7 of Loopdidoodle?" Oh, I think I need 3.3.4. But the developer of my GUI framework says only 3.3.2 is tested and I'm on my own if there are problems. Somebody has a workaround but it only runs on RedHat when I'm running Debian. Should work okay if I recompile it, though... except the kernel version I'm running is too far behind.

And your assumption third party libraries are any better quality than a focused in-house solution is a bit naive.

Finally, a few years down the road the mind share for half your third party libraries and frameworks will have dwindled as the people you were counting on to maintain them found something shinier.

Re: The Duct Tape Programmer

#42

Post by fit2rule »

tragic wrote: post #27
fit2rule wrote: post #21

Earlier quoted context omitted.

Every time you bitch, consider this: you've still got users. It'd be appropriate to bitch about it if you didn't have users. But, in the end, it doesn't matter how fancy things are: the user is the only thing that matters. Ever.

Until the users want a new feature - save/load, say - and you can't add it without breaking the toaster in the office kitchen. And so the users bugger off to play Candy Crush Massacre or whatever :-)

So this is why you release early and often, and work hard to fix the problems before your users get to them.

Re: The Duct Tape Programmer

#43

Post by mercer »

Untit1ed wrote: post #14

The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.

Seems like a good context to recommend the wonderful 'Simple Made Easy' talk by Rich Hickey, the creator of Clojure.

http://www.infoq.com/presentations/Simple-Made-Easy

Re: The Duct Tape Programmer

#44

Post by collyw »

tsotha wrote: post #41
collyw wrote: post #40

Earlier quoted context omitted.

I would far rather have something put together with well known, documented, tested third party libraries than some undocumented in house crap that one "superstar" developer knows how to work and no one else.

You think that, but in my experience the "well know, documented, tested third party libraries" try to be all things to all people. So when you just need something to cut your steak with what you get is a Swiss army knife with twenty different blades of which you can identify three without spending a week poring through documentation. Instead of just looking at fifty lines of code to see what the "undocumented in hous…

Documented and well known is preferable to most of the in house stuff I have come across. Need a Django developer, then there will be a few out there. A new developer on your own in house framework is always going to need some time to get up to speed.

Sure I may be on Stack Overflow for some answers, but you can guarantee that the in house equivalent won't have any Stack Overflow answers at all.

My personal experience is that open sourced libraries in CPAN / PyPI are almost always of a higher quality than in house stuff.

Maybe it depends on the language. When I go for Python / Perl libraries, I usually get something of a high quality. JavaScript stuff always seems a bit more like you describe.

I would say that the developer of the in house stuff leaving is going to be at least as much of a problem as people abandoning open source projects (which are open source, so you can continue to maintain them yourself).

Re: The Duct Tape Programmer

#45

Post by waps »

sgift wrote: post #26
Untit1ed wrote: post #14

The problem with this blog post is that it's long been used to justify writing crappy code, when it's actually about writing simple code, and those aren't necessarily the same thing. If your duct-tape go kart falls apart going around a corner and gives you a permanent injury you're gonna wish you spent a bit more time at the starting line wondering what to build it out of.

> you're gonna wish you spent a bit more time at the starting line wondering what to build it out of. Sure, but usually spending a bit more time at the starting line (or rather "much more time" or "all the time in the world, until there's no time left and you still have to use the duct tape version, now in an even bigger hurry") won't help you find the problem spots. Hindsight bias is very well and alive and usually…

As a general rule, decision made due to regret ... well tend to lead to more regret. That happens to me a lot. What a lot of people don't do after a project is to first evaluate how well the whole thing worked.

How many bug incidents were there ?

How many times did a design decision have to be refactored out ?

How many times did you really have a problem ?

Then, first things first, take out all problems that were obviously not project related. The team moved ? Someone went on holiday ? All of those don't matter.

After that, you'll have problems left. If it's 3 problems, none of which delayed more than 2 weeks/10%, your project went as well as you can reasonably expect. Don't change a thing. If after that you arrive at the conclusion that the project went ~80% as planned, then you've simply done it right. There are no lessons to be drawn from mistakes, because the fixes are likely to screw you up more than the "mistakes".

Even when this is not the case, you should limit fixes. Take the top-3 problems, at the very most, and implement a fix for one of them. Then try to mitigate the second and stay away from everything else.

If you don't you'll have seriously more regrets about your next project a whole than your current project.

Lots of people generally don't do this. They do a project, then switch programming languages. That's a decision you should make once in 5 years (unless you're switching back after a disappointment). People seriously overcompensate. From management to developers. Redesigning an entire organisation because one bad apple leaked something is very likely not justified, and similarly a rewrite is almost never justified.

Re: The Duct Tape Programmer

#46

Post by fit2rule »

collyw wrote: post #38
fit2rule wrote: post #22

Earlier quoted context omitted.

>Multiple inheritance often makes it extremely difficult to tell where my code is coming from. Thus the rise of the "can't do anything without an IDE" developer ..

What exactly is the problem with IDE's? Why should I have to learn a hundred cryptic keyboard shortcuts to get what I consider normal functionality? I have in the past used Perl's command line debugger. Why would I want to do that when I have a far more efficient graphical debugger in Eclipse? I work with bioninformaticians, and many of them are too lazy to have ever set up an IDE. Most of them won't have had autocom…

What exactly is the problem with IDE's?

  You appear to be advocating a new:

  [ ] cloud-hosted [ ] locally installable [ ] web-based [ ] browser-based [ ] language-agnostic
  [ ] language-specific IDE. Your IDE will not succeed. Here is why it will not succeed.

  You appear to believe that:
  [ ] Syntax highlighting is what makes programming difficult
  [ ] Garbage collection is free
  [ ] Computers have infinite memory
  [ ] Nobody really needs:
    [ ] a REPL  [ ] debugger support  [ ] a local filesystem
    [ ] to interact with code not written in your IDE's preferred language
  [ ] The entire world speaks 7-bit ASCII
    [ ] Scaling up to large software projects will be easy
  [ ] Convincing programmers to adopt a new IDE will be easy
  [ ] Convincing programmers to adopt a language-specific IDE will be easy
  [ ] Programmers love learning new keybindings
  [ ] There is only one operating system and it is
    [ ] OS X  [ ] Windows  [ ] Linux  [ ] iOS  [ ] Android  [ ] the DOM

  Unfortunately, your IDE (has/lacks):
  [ ] vi keybindings
  [ ] emacs keybindings
  [ ] Syntax highlighting
  [ ] User-configurable indentation
  [ ] Macros
   [ ] Written in JavaScript [ ] Written not in JavaScript
   [ ] Written in a scripting language you made up
       [ ] which is a Lisp
         [ ] A windowing system
  [ ] Version control
   [ ] Only using git [ ] only using github.com [ ] not using git
   [ ] using an RCS of your own devising
     [ ] Its own platform-independent look-and-feel
   [ ] that was designed by a programmer
   [ ] based on yesterday's design fads
   [ ] applied inconsistently
     [ ] A look and feel specific to one operating system
   [ ] that was last widely used in 1989
   [ ] and was known to cause seizures

  The following philosophical objections apply:
  [ ] Programmers should not need to understand CSS to change their font
  [ ] The most significant program written using your IDE is itself
  [ ] The most significant program written using your IDE isn't even itself
  [ ] Graphical programming presumes programmers can draw pictures better
    than they can type words
      [ ] The implementation is closed-source
    [ ] covered by patents  [ ] not owned by you
      [ ] The DOM is not an application framework
  [ ] The name of your IDE makes it impossible to find on Google
  [ ] Your IDE assumes JavaScript can be made infinitely fast
  [ ] You seem to think static analysis is worthless

  Your implementation has the following flaws:
  [ ] JavaScript is not faster than C, C++, or Java
  [ ] The DOM is not a windowing framework
  [ ] It crashes on any file larger than 32k
  [ ] You provide no way for users to run the program they are editing
  [ ] You require the user to check in code before it can be run
  [ ] The IDE crashes if you look at it funny
  [ ] You don't seem to understand basic optimization techniques
  [ ] You think a single string is an acceptable data type for a text editor

  Additionally, your marketing has the following problems:
  [ ] Unsupported claims of increased productivity
  [ ] Unsupported claims of greater "ease of use"
  [ ] Obviously faked screenshots
  [ ] No one really believes that your IDE is faster than:
    [ ] vi  [ ] emacs  [ ] Eclipse  [ ] Visual Studio  [ ] IntelliJ [ ] Notepad
      [ ] Rejection of orthodox user interface design without justification
  [ ] Rejection of usability principles without justification
  [ ] Rejection of established platform conventions without justification
  [ ] Rejection of basic user interaction without justification

  Taking the wider ecosystem into account, I would like to note that:
  [ ] Your example workflow would be one key command in: _______________________
  [ ] We already have an IDE in the browser
  [ ] We already have an IDE that can be scripted using
   [ ] Python [ ] JavaScript [ ] A Lisp [ ] Lua
     [ ] You have reinvented vi but worse
  [ ] You have reinvented emacs but worse
  [ ] You have reinvented TextMate but worse
  [ ] You have reinvented Eclipse but worse
  [ ] You have reinvented Notepad but worse
  [ ] You have reinvented Notebad better, but that's still no justification
  [ ] You have reinvented ed but non-ironically

  In conclusion, this is what I think of you:
  [ ] You have some interesting ideas, but this won't fly.
  [ ] This is a bad IDE, and you should feel bad for creating it.
  [ ] Programming in this IDE is an adequate punishment for inventing it.

Re: The Duct Tape Programmer

#47

Post by Chyzwar »

habosa wrote: post #4

Sometimes duct tape is the way to go, especially when you are working on a project with a small-ish team where your 'hacks' can be easily understood by everyone. This article is very relevant to my life recently. Recently I have been working on a tool to boot a full development environment in VM. It's just a series of shell scripts (managed by Vagrant, so some "shiny", but nothing crazy). Everyone wanted me to use do…

Yes, then 3 years later I need to deploy something new on same server where your "simple" scripts are working. I my current project I need to work on CentOS 5.8 where I cannot install anything new and performance suck.

On the other hand Docker container would create separate env for application that will be fully independent. If you can pay for Vagrant I/O penalty they go ahead.

Re: The Duct Tape Programmer

#48

Post by habosa »

Chyzwar wrote: post #47
habosa wrote: post #4

Sometimes duct tape is the way to go, especially when you are working on a project with a small-ish team where your 'hacks' can be easily understood by everyone. This article is very relevant to my life recently. Recently I have been working on a tool to boot a full development environment in VM. It's just a series of shell scripts (managed by Vagrant, so some "shiny", but nothing crazy). Everyone wanted me to use do…

Yes, then 3 years later I need to deploy something new on same server where your "simple" scripts are working. I my current project I need to work on CentOS 5.8 where I cannot install anything new and performance suck. On the other hand Docker container would create separate env for application that will be fully independent. If you can pay for Vagrant I/O penalty they go ahead.

The scope of my project isn't what you think it is. The goal is to provision a VM with an Android development environment on it, just for the purposes of getting newbies up-and-running. So nobody will be relying on my scripts in a few years.

Re: The Duct Tape Programmer

#49

Post by [deleted] »

skatenerd wrote: post #19

Multiple inheritance often makes it extremely difficult to tell where my code is coming from. When you don't use inheritance, you often get to refer to another module by name . E.g. `my_dependency.fetch_data(123523)` With multiple inheritance, however, that other module has become your own "self"! Suddenly you're stuck with: `self.fetch_data(123523)`. And if you want to find the source of `fetch_data()`, you basicall…

[deleted]

Re: The Duct Tape Programmer

#50

Post by raiph »

skatenerd wrote: post #10
DownvoteMeToWin wrote: post #9

Currently rewriting every single line of UI code a pile of duct tape programmer spewed out over the span of two years. Writing functional tests so I know when I break the UI. Documenting everything. Hitting all deadlines. Using multiple inheritance. Lots of It. In fact, no file is over 150 lines long. Composition pattern in full effect as well. I hope it wards off duct tape programmers for life. > 2015 > multiple inh…

Composition...isn't the same as inheritance?

No. The Yo-Yo problem was one of the primary themes of ECOOP 89, the European Conference on Object Oriented Programming from 26 years ago.

https://en.wikipedia.org/wiki/Yo-yo_problem

Post reply on HN