#1 Rule of Programming Is..There is no Rule #1
sure there is. mine is: automatically assume that every user is out to hack/deface/fuck with your app.
First Rule of Programming Is Don't Program
51–60 of 90 posts
Re: First Rule of Programming Is Don't Program
#52That 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 investigate 3rd party options.
That said, developing internally is sometimes the only answer: when you don't get a good feeling from the 3rd party options (based on research), when the 3rd party cost is too high, etc.
Of course... it's usually more fun to develop internally. :)
Re: First Rule of Programming Is Don't Program
#53Mixing in a bunch of other non-related "off the shelf" code can lead to unmaintainable code, licensing issues, poor performance, unexplained behavior, missing documentation, inherited bugs, and not being able to modify a library to your own needs. I would hate to be part of a project that adopted this philosophy. Constantly reinventing the wheel is not good either. Finding the right mix of knowing when to leverage existing code and when to write your own is when you win.
Re: First Rule of Programming Is Don't Program
#54"Use VB.NET or Delphi for the front-end user interface." Or, you could use something that's cross platform like Python.
Using which Pythonic stable, tested, documented drag-n-drop GUI/RAD toolkit?
Re: First Rule of Programming Is Don't Program
#55I actually think the reverse of this is the biggest problem in our industry. From my experience most programmers I've worked with don't understand the underlying mechanism that make their tools work. And when they hit a bug or a problem their tools weren't designed for, the shit hits the fan. And I've seen the reverse of what you're talking about quite a lot ... developers or managers choosing off-the-shelf software…
I also think that the "use a third party library" mentality can, but not always, cripple programmers.
I've almost always written something that has less features/worse code/more bugs than a library that would have been a perfect fit. And I did it intentionally.
Why?
Because I learned something new. I've written my own C++ DirectX game library... then went out and used HGE/Goblin 2D. It made me a better programmer because I understood why the design decisions were made because I had similar problems when doing it myself.
I've written my own PHP framework. Why? Same freaking reason. I can look at similar frameworks, CakePHP/Django and quite literally see what it was they were doing under the covers without looking at the source because I've solved the same problem myself.
In the event that there isn't a third party library out there that does what you want, the programmer who is accustomed to look for those first will be screwed. They've never had to make a large system by themselves and they don't understand ahead of time what types of problems they'll run into because they've used other frameworks that have prevented them from making those mistakes.
tl;dr; Using a framework just because its there is similar to a parent coddling a child. When its time to enter the real world they simply won't be ready.
The anecdote here, I believe, is knowing when doing it yourself is a great learning experience, vs a COMPLETE waste of time. Always doing it yourself is stupid, but never doing it yourself is the easy way out.
Re: First Rule of Programming Is Don't Program
#56I always try to find a library which does what I need before writing one myself. However, I rarely consider proprietary libraries.
With open source or free software libraries I can quickly get some idea of how well-written the library is, and how well it can be extended in the directions I need it it to.
In rare cases I might pick a propietary library for a project at work, but even then I only pick those for which I get the source code. When a client calls with some issue which needs an immediate fix, I can actually dive in and fix things.
Re: First Rule of Programming Is Don't Program
#57I'd say first rule of programming is KISS. It kinda includes your rule.
Re: First Rule of Programming Is Don't Program
#58Earlier 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).
One remarkable attribute of IKEA is its epic success. In fact, its owner is arguably the richest man in the world [1].
[1] http://en.wikipedia.org/wiki/Ingvar_Kamprad#Net_worthRe: First Rule of Programming Is Don't Program
#59Agreed. I would broaden the #1 Rule of Programming to be: SOLVE PROBLEMS. Sometimes you do this by programming it yourself, sometimes by doing it off-the-shelf, but if at the end of the day you've solved someone else's problem, they will give you money.
Yup, you are right. But solve problem your best and as fast as you can :-)
Re: First Rule of Programming Is Don't Program
#60Also: 9 times out of 10 you can do something faster by hand even if you think that a shell script, regex/sed command, or custom emacs extension would do the job better.