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

First Rule of Programming Is Don't Program

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: First Rule of Programming Is Don't Program

#61

Post by [deleted] »

jaddison wrote: post #52
viraptor wrote: post #33

That looks like the manager's (or any other person spending money, not writing code) point of view... In reality you missed a couple of things: - Buy an off the shelf program and take 3 hours to read their proprietary API for extra functionality. Then learn that you cannot integrate it into the current system (because of licensing, data format, missing features). Since you cannot make changes to the off the shelf pro…

I'd say that if you're buying an off the shelf program, it's likely because implementing it would take FAR longer than the (example) 3 hours to investigate their proprietary API. I think there is still a valid trade-off in purchasing - it just has to make sense, is all. If the problem is big enough that it's unwieldy enough (ie. take too long to develop and TEST internally), then it definitely makes sense to investig…

[deleted]

Re: First Rule of Programming Is Don't Program

#63

Post by xcombinator »

mcotton wrote: post #46
pretzel wrote: post #43

Earlier quoted context omitted.

>This philosophy leads to becoming the IKEA of software. As in the most succesful?

If that is what you are going for, then yes. There is nothing wrong with that strategy. I haven't found anything remarkable at IKEA (except for price).

I have. My office leather chair was bought in IKEA more than ten years ago. It was cheaper than alternatives, I bought the alternative because I wanted something good that last. It lasted 6 months of use, I had used a lot of chairs in my life,and all broke fast(I'm tall, maybe that's it) I think my IKEA is way way better in terms of quality, not only price.

I have lived in places with old mahogany furniture(from Congo), strong, beautiful, heavy wood, I prefer IKEA furniture for living, I don't need to care if I broke it, is lightweight, and I don't feel bad about the environment.

Having someone do something using his own hands doesn't mean is better, in fact, it uses to be worse, compare a Toyota manufactured with robots to a handmade car and tell me.

Re: First Rule of Programming Is Don't Program

#64

Post by edw519 »

I wonder what OP has seen to reach these conclusions because this is not my experience. Not even close.

What I have experienced in commercial environments:

- Software make/buy decisions are rarely made by programmers, but are made strategically with programmer input.

- "Everything else (95%)" can be many things. Sometimes you can plug in standard stuff (utilities, human resources, accounting), often you must write original code to handle your company's proprietary processes.

- In theory, existing libraries and frameworks are great. In practice, sometimes they make sense, but just as often they force you into a dead end. It may be tough to code at a low level, but the advantage is that you can almost always do what's needed.

- Having source code and being able to do something with it if often a huge competitive advantage. I forget how many times I've witnessed M & A scenarios where the acquirer bought the acquired because the former was able to change their business software on the fly and the latter had an unchangeable package.

Re: First Rule of Programming Is Don't Program

#65

Post by ErrantX »

jaddison wrote: post #50

I'd say it can be simplified even further: THINK before you SOLVE. A natural tendency for programmers/developers is to move towards a knee-jerk reaction of "I'll just start coding this". It's not that good solutions don't come up from that line of thinking; it's more that - as cyman states - there are faster ways to accomplish results if you simply think about how you're going to solve the real problem(s). Once a pro…

I believe this is actually a much better rule.

There is the other knee jerk (and a dangerous one) to do the reverse and just use off the shelf kit for large swathes of functionality.

We have one contractor who did just this and it currently the project is 3 months overdue as he is reworking large portions and sections so that it can do the things we originally asked of the program ;)

Formulate your approach then decide what can use pre-built packages and what needs to be hand coded.

"Dont program" can be as dangerous as "knee jerk" programming.

Re: First Rule of Programming Is Don't Program

#68

Post by bkovitz »

rick_2047 wrote: post #22

I would like to take a poke at the automobile engineer analogy. I think the reason they don't build there own parts is because of one of the two: [1]They don't know how to build it.These parts are sometimes too advanced for a single engineer to build.This is because there field of engineering has advanced to a level to which,I think, software engineering has just not reached. [2]They don't have the experience points…

"tangible"?

Re: First Rule of Programming Is Don't Program

#70

Post by jrockway »

I would never buy a library, but I've never had that option either. Every tool I use is open source, and I build small proprietary applications around the open source stuff. (Making web pages and parsing CSV files is not my business domain, so I let the community handle those.)

I will say this -- the first step to not writing too much code is to reuse your own "internal" code. It's simple; instead of cut-n-paste-n-modify, make it a library, and make the per-app "modification" some different parameters you pass to the library. Now a bug that affects all the possibilities can be fixed everywhere at once. And, if someone understands one app's usage of this library, they will understand the other app's usage, as well. Less to think about, less code to maintain, and nothing to buy.

The next step is letting other people fix your bugs for you. My last job was for a company that routinely factored out part of their apps into community libraries. If you use Perl, you probably use Moose -- that was a piece of an internal app at one point. Releasing that bit of code changed the entire Perl community, and it made maintaining our software even easier. There are plenty of times I've hit a Moose bug only to have it fixed in 30 minutes by Someone Else. (To be fair, I've fixed other people's Moose bugs too.)

So anyway, the word "reuse" is thrown around a lot, but it is really an important concept. I have reused every piece of code I've written in the last few years -- once in my application, and once in the test suite.

If you're not reusing your code at least once, you're doing it totally wrong. If you're not reusing your code more than once, you're missing out on a lot of good things.

Post reply on HN