Programming - A perfectionist's worst nightmare? 2

[keyser456]

Five months after quitting my old job to become a self-employed programmer I find myself wondering if I made a mistake. I have not seen a real paycheck in five months. Instead I've been developing the product I'm intending to sell. I'll be the first to admit that when I quit I was not ready for the overwhelming amount of work involved in design, implementation, debugging, and documentation of a commercial or enterprise level application.

The experience has been worth it overall. Over the past five months I've learned more than I could have ever learned in college. My teacher? The wealth of programming info on the internet, some books I've bought, and a whole lot of trial and error. I've been able to learn new concepts and test them at my own leisure, without worrying about deadlines or having someone watching over my shoulder.

Unfortunately, one thing has become increasingly more clear to me; I'll never be happy with my work. On the outside, my forms and controls pull and push data faster than any other data-driven programs I've seen to date. However, I just can't get over all the little internal imperfections in my code: the workarounds, the hack jobs, the corners I've cut. I know I can write better code, and this knowledge is hands down my worst enemy. Instead of pushing forward with my project to actually create something marketable, I spend my time making more efficient algorithms and classes. The sky is the limit as far as improving code goes, and as I look at my modest program, a program aimed at small manufacturing companies, I realize the work I've done is equivalent to building a nuclear bomb to kill a spider in the front yard. Rather than concentrating on killing the spider, I'm stuck on the fact that I can build an even bigger bomb.

I've really done a lot of thinking about this, and I haven't decided whether this idea of perfection will help me or hurt me in the long run. Nothing bothers me more than a slow, bloated, and inefficient program with bugs, but at least the makers of these same types of programs are able to pay their bills. Maybe they've been in my shoes before and figured they had to draw the line somewhere? I guess I'm still deciding on where to draw my line. So... where do you draw yours?

 

[RoyVidar]

Look at the applications you're compeeting with. Do they do the job? Are they reasonably priced? Are they perfect? (for that sake, look at market leeding other software products - are there any perfect ones?)

I think the clue is to determine what is good enough (just a bit faster, and a bit less bugs than the competition), deliver that, and collect the paycheck. Striving for perfection and doesn't always feed the family and pay the bills. Besides, you'll easily end up being to late with your product, too;-)

But by all means, learn as you go, then your next update/revision/update/version will be even better and faster.

Roy-Vidar

 

[11011110000]

I knew an individual who developed a full-fledged accounting program, and spent years developing it part time. When it came to marketing they wanted 80% to cover marketing costs, and he never did anything with it.

Make sure you have a marketing and business plan or your efforts are futile.

 

[infinitelo]

Thanks RoyVidar, Im in very early stages of my own part
time project and was finding myself in that infinite loop of trying to get it perfect. Sometimes you just have to kludge and move on, if you know a piece could be better, make a note for a later version. (m$ model????)

I've always believed that perfection is something only God can reach, for mankind it is an unstable state. As you approach perfection, disaster is sure to come next.

Is is good enough? Only the market can tell for sure, you need third party testers.

if it is to be it's up to me

 

[MikeLacey]

Hi keyser,

Being your own project manager is one of the hardest things to pull off successfully.

On the surface it's quite different working on your own, it's difficult to step back and look at the work involved from one level back.

Actually though - you need to be harder on yourself than any project manager could be (even me)

Can I suggest that you plan out, at a schedule not a detail level, the work needed as if you were having the work done by someone else. Set realistic deadlines for this programmer - who just happens to be you - and look at the overall schedule each time a deadline slips.

I think you're attempting one of the hardest tasks around, if you can do this you can do anything.

Mike

To err is human,
but to really foul things up -
you require a man Mike.

Want to get great answers to your Tek-Tips questions? Have a look at faq219-2884

 

[GMcNamara]

Perhaps the most important thing to look at is return on investment. I have suggested millions of changes to our system, but I never get the go-ahead unless the company can recover the development costs.

Business is business and as difficult as it can be sometimes, you have to check your ego at the door.

 

[MasterRacker]

As you learn more you'll always looks at your older code and wonder what you were smoking when you wrote it. Keep your eye on the end result and the problem you're trying to solve instead of the underlying mechanics.

Think of a game of pool. Even if I break and run out, at least once during the rack, I'll be out of position, need to change my plan and recover from the error. The end result is the same as the mythical perfect rack however, a win, where the opponent didn't get to shoot at all.

Since we're all human and none of us are perfect, striving for perfection is a waste of time. So don't do it. Strive for excellence instead.


Jeff
The future is already here - it's just not widely distributed yet...

 

[chiph]

MasterRacker is right. I was in some code I wrote about 2 years ago, and was really shocked how bad it was.

The usual reason -- I was under a deadline and there wasn't time to do it right...

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[KornGeek]

As you learn more you'll always looks at your older code and wonder what you were smoking when you wrote it.

That is one of the most accurate statements I've ever seen. Even though it is phrased in a humorous manner, it is also 100% correct.


Another thing to consider when you're developing your software is your target audience. Many times, especially when dealing with less technical end-users, putting in too much functionality can actually be a negative. I've seen workers flat out refuse to use software because they felt it was too complicated. Management dealt with the situation by letting a few of them go, and the resistance faded, but it never went away.

Don't overdo it just because you think it would be good. Consider your target audience and what they want.

 

[TomKane]

I've seen workers flat out refuse to use software because they felt it was too complicated. Management dealt with the situation by letting a few of them go, and the resistance faded"

I found that laugh out loud funny. I wish we could fire some of our awkward users.....

 

[jsteph]

As you learn more you'll always looks at your older code and wonder what you were smoking when you wrote it.

And if this is not true it means you've stagnated and are no longer learning, so this is always a good sign to see your old code and think that.

Look at the applications you're compeeting with. Do they do the job?

So true. You can look at glossy brochures and fancy splash-screens of commercial software and think it's all so magically perfect, but in reality it's just written by blokes like you and me, and it's all full of the same bugs and issues we all face in our programs.

Take SAP for instance (please!). So huge, so slick looking, a list of Fortune 500 and 100 companies to impress anyone. Once I started learning ABAP and getting under the covers of this, I found a colossal mess of questionable architecture and design, inefficient programming, clunky interface, etc etc.

Yet in the end it works. And it sells, because in large part it does what it says, messy as it may be, and it is reasonably robust.

So if your nuclear bomb kills the spider, then go out and sell it as is and start collecting a paycheck.
--Jiim

 

[Chance1234]

Learn to say to yourself, "Now is the time to down tools". Trouble is when your working on something at leisure with deadlines that are only self imposed, you loose the importance of deadlines themselves.

You need to think if i was project managing XXX for someone else and i kept putting the deadline back, i wouldnt last very long.

Have a deadline, stick to it.

Chance,

Filmmaker, gentlemen and forum1229

 

[MasterRacker]

jsteph has it right. As coders, we all have a tendency to get too elegant. Remember that fancy techniques you use may end up being above the head of the junior programmer that's stuck with maintenance programming on the product years after you are gone. Their "maintenance" may end up introducing all kinds of unnecessary bugs because they don't understand how the original actually works.

Also, The bottom line is that all programs are written to solve a problem. Very few of us have the luxury of coding for the sake of coding. No matter how ugly and clunky the code is, if you end up with a product that from the end-user's view solves the problem better than competing products, you have a winner.


Jeff
The future is already here - it's just not widely distributed yet...

 

[dilettante]

Sometimes the reasons why somebody should by your product are intangible, even when the rationale seems clear on the face of it. I have a server-side web product that's a tough sell, because competitors are a dime a dozen.

The competitive advantage I offer is that mine is much less hackable than its competitors (I know better than to ever claim something like "hack proof"). But how do you prove (i.e. measure) such a thing? How do you demonstrate it convincingly to your market? This is especially hard if they already use a competing product, and face paying a second time for the same capabilities. They need a solid case for shelling out the bucks again.

My point is that once you get past the initial "perfection" of your software product you often have to "perfect" your marketing. This can be more work than the original software effort.

In my case I've been put in the awkward position of accumulating working hacks of some competitive products. Now I have something to demonstrate? Well, aside from the ethics, all I can show is how the competition can be hacked, not that my offering can't be. Sometimes the answer seems to be "hire a slick sales team" which undermines the whole effort due to the costs.

The only real hope is to gain momentum or "buzz" in the market. Once enough (the right?) people start saying the right things about a product, it gains a foothold - whether those things are necessarily true or not. Until then, you're swimming upstream.

So the headaches only begin with the programming, testing, documenting, packaging, and support (ugh!). Support (hand holding) is a topic in itself. But the "selling" is a whole new level of frustration. Independent software development in the 21st Century - what a roller coaster ride!

 

[Terpsfan]

One thing I've done is actually go back to some of my previous projects and after laughing and crying, re-developed it in a much more efficient manner.

There was a time when I was excited about how much code I could write. Now I am more excited about how little code I can write to do the same thing as before.

If you seek to develop the perfect application, you will always be living in a world of frustration and stress. You have to get to the point of letting go of the fact that it isn't perfect and will never be perfect.

Another sobering fact is no matter what application you have created, chances are good that somebody, somewhere has done it just as well or better.

I like to read books, web sites and anything I can get a hand on to see how other programmers approach applications. I get ideas I never thought of before.

Your application is probably much better than you think it is. When you're developing the application, you can never look at it objectively. This application is the work of your own hands. Think of the hard work you've put into it and how you have pushed yourself past the envelope to get it done.

 

[KornGeek]

Along the lines of what dilettante wrote,

I work for a smaller company, and one of our chief software packages has a lot of competition. When we started, what often won us the contract wasn't so much what our software could do, as it was the support we could offer.

One of our big competitive advantages is that we tend to offer upgrades (at no charge if you have a current maintenance agreement) periodically. Customers are much more forgiving of errors they may find if you fix them and throw in a few bells and whistles.

After developing a good reputation and refining our software several times, we now offer some actual benefits over competing software. It was an uphill battle, but you sometimes need to adapt to the situation. Remember, the best solution is not always the one that sells. This can work to your advantage in the beginning, and can work against you later.

I recommend rolling out your software to a few beta sites and getting their feedback. You may think it is the best software in the world, but customer opinions can be quite sobering.

As far as continually improving your code, remember that the "best" code depends on your needs. For instance, look at sorting algorithms. Quicksort is generally very fast, but does not preserve sort order. Good old Bubble Sort might be better if you only have a small amount of data, because it doesn't take long to code.

Sometimes saving time coding is more important than having it run a little faster.