nizo's Journal: Why do I do this?

The next time you're knee deep in arcane language geekery, remember this: nobody cares what your code looks like. Except for us programmers. Yes, well-factored code written in a modern language is a laudable goal. But perhaps we should also focus a bit more on things the customer will see and care about, and less on the things they never will.

From: http://www.codinghorror.com/blog/archives/001022.html

I have all these ideas for code, websites, etc, but inevitably I spend inordinate amounts of my time worrying about things that, while they do matter, are not important enough to stall an idea. But sadly they keep me from actually finishing (or even worse, getting started) on a whole variety of projects. For example, yeah it is important to design a site that works in as many browsers as possible, uses CSS, etc. etc. but why the hell can't I just write the basic site (using html and php, that will work just fine in 90% of the browsers out there) and worry about all the little niggly bits later?

And of course this isn't just limited to coding; many things in life I don't even start, because I have the absurd expectation that if I don't do it perfect right away, I shouldn't even start. So rather than run the risk of having several lame drawings, I have none, and have learned nothing. Why?

Learned from a pro...

[RM6f9]

Negotiate a truce with your inner judge/editor: Tell it when you have invested X hours/days into the project, you will let it have a full meal of y hours, but until then, it needs to leave the area thus leaving you free to *create*.

The pro I learned this from? Richard Bach, of "Jonathan Livingston Seagull", et al, at a reading he did in Seattle for "Out Of Our Minds" - he said he'd had the same issue early in his career and he decided he was a much better author than he was an editor, so he did his authoring first and most, editing second and, well, less.

Re:

[nizo]

Sometimes I think I am a better editor than a writer :-| And yet I still want to write...

I love that book; it is very cool that you got to meet Mr. Bach. How are things going btw? Email me if you don't wanna spill the beans here :-)

Because...

[Yaztromo]

but why the hell can't I just write the basic site (using html and php, that will work just fine in 90% of the browsers out there) and worry about all the little niggly bits later?

Because if you worry about the "niggly bits" later, you'll find that you haven't sufficiently planned for them, necessitating either a (potentially) time-consuming re-factoring of your code, or at worst scrapping all your work and starting over again (actually, I lied: at worst, the original code will be so bad that you simply won't want to work on it anymore, and will let it wither and die).

Code maintenance is a significant issue; roughly 70% of the cost of software projects is in maintenance. If you use good designs in the beginning to ease overall maintenance, you're going to have lots of time to do all sorts of cool things down the line, instead of re-writing everything to wind up with the exact same functionality in order to be able to eventually add new functionality.

With all that out of the way, I think it is possible to start off with a small and well-focused project which is also maintainable. Perhaps your real problem is you just want to try to jam too much functionality into version 1.0, instead of starting off with a limited feature set and focusing on future maintainability (and expandability)?

I'd disagree with the quote you started your journal entry with, in that it seems to pre-suppose that users don't care about software change over time. They do. They're pretty much going to expect that you continue to work on and upgrade your software in a timely manner to improve functionality, reduce bugginess, and add new features they're interested in. You have to plan for this; few organizations and individuals in this industry stick with technologies that have no future and will never be maintained or improved. So those bits underneath do matter if you're interested in the long-term viability and usefulness of your code; the faster you can respond to feature requests and bug reports, the better off the entire system will be (and you'll have happier users too).

So if it's the "niggly bits" which appear to be time consuming and are going to cause you to simply put off the initial implementation, reduce the scope of your project (for my OSS projects, if I want to create an application that does X, I usually try to start off by creating an API for more easily doing X, and worry about creating the application to do X later. This tends to work especially nicely in OSS, as it causes me to reduce and focus the scope (and time requirements) of my first efforts, and it allows other developers to use my API/library output in their own projects while I get ready to write my own applications).

Yaz.

Re:

[nizo]

Excellent points to consider, and you know what: you are right. I probably do want everything and the kitchen sink up front, but designing, say, one kitchen cabinet, keeping in mind that down the road I want more, is a great idea. Though I shouldn't try to make a perfect cabinet initially either, especially if designing the perfect cabinet forever and never building anything means I end up with no cabinet at all.

Re:

[Yaztromo]

Though I shouldn't try to make a perfect cabinet initially either, especially if designing the perfect cabinet forever and never building anything means I end up with no cabinet at all.

True enough -- there is no reason why the development cycle can't be iterative, with improvements along the way. What I tend to like to encourage however is that the back-end stuff should be well designed at the outset -- don't just ignore it in order to solely work on the front-end glitz. To borrow your example, you pro

Re:

[nizo]

...door right into the frame so that it looks beautiful, but can't be opened...

Funny you should mention this. I did indeed make a "cabinet", and due to poor planning and inexperience, it ended up having a door I couldn't open :-| While it did waste my time and money, if I were to do it again, I could draw on the experience from building that one to build a much better one (or more likely in this case, buy a better one :-D) And of course I ended up taking it partially apart and making a functional (though su

Re:

[queenofthe1ring]

I remember a while ago you mentioned the book "getting things done" and how you and checked it out, but had not had time to read it then. Well, that is one thing he talks about as being a very important motivator: deadlines. Basically every task that you are serious about doing should have it's own subtasks with deadlines.

It might be worth checking out again, if you haven't read it all the way through. It gave husband good ideas on how to increase his productivity and organization. Me, I'm just a m

Re:

[sillypixie]

Of course it's better to build something broken and learn -- when you've done that, you have "experience" and this is the great thing about coding. No matter which choice you make, or which approach you take, it is possible to build broken things - the breaks are mostly detected and discarded at different times - but they still happen.

You see yourself as going around in circles. You aren't. Every time you work through these things and then try things and judge the result, you're building a repetoire of t

Good question without an answer

[bersl2]

I have the same problem. Sometimes I'll vacillate between several ways of writing equivalent code, and then several ways of formatting each of those.

Because you are afraid of failure?

[The Fun Guy]

I had a great idea!

OK, getting ready to implement the idea! Let's read up on this!

Hmm, other people have had similar ideas, but mine still looks pretty good.

OK, this will be harder than I thought. Maybe my idea actually sucks, and all of this will be wasted effort and I'll look like an idiot for even suggesting it. These guys know a lot more about this than I do. I better get all of my ducks in a row or I'll really look like a half-baked rookie.

The only way I'm not going to fail is if every single part of my plan is bullet-proof. I won't show this to anyone until I'm sure it will work. Which is to say, until I'm sure I won't fail.

This 90/10 rule sucks. I don't even know HOW to take care of all this little details and it's taking forever to learn how. It's a good thing I'm not going to show this to anyone for a long time.

I'm not going to show this to anyone. At least no one saw how unprepared I was. It doesn't matter, though, because I have another great idea in another area of endeavor!

That's how I do it, anyway. Living in terror that people who know a lot more than I do are going to laugh at my amateurish attempts. I'm talking about what I do for a living as well as what I do for recreation or as a hobby. However, I'm also stubborn and egotistical enough that I went ahead and put my stuff out there anyway. I'd already come to the understanding that perfection is the enemy of progress. Taking the hits to my ego hurts, but it's the only way to learn and grow. You didn't see Bruce Wayne make mistakes in the learning process because he did it in Tibet.

If I'm way off base, then feel free to ignore. If any of this makes sense, I found this book to be useful in defining what was going on inside my head: The Positive Power of Negative Thinking [google.com].

Similar?

[Shadow Wrought]

Perhaps similar, but I sometimes think of it as self-sabotaging. If you never start the project, then the project can never fail. Sort of a horrendous failsafe against having to suffer failure. YMMV, but I've certainly found that my biggest obstacles have been more myself than anything else. So I'm trying to convince myself that something is better than nothing. A failed short story was at least written, just as a failed website was at least posted. Partial credit > no credit.