Subscribe to Stuck in an Infiniteloop        RSS Feed
-----

All Software Sucks

Icon 4 Comments
Now, if you would kindly hold onto your torches and pitchforks for a few minutes, I can explain. It isn't that your new awesome killer app written in the latest shiny toy you found in a box won't be the best thing since sliced Google bread; rather, your app will never be perfect.

Why?

Assume for a moment that you're writing a hello world program in a compiled language, let's say C:

#include <stdio.h>

int main(){
     printf("Hello World!\n");
     return 0;
}



At this point, you're already operating on at least three levels of abstraction. Your code is compiled, linked, assembled, and then run via the shell of an operating system, of which itself is also a program compiled, linked, and assembled running on hardware governed by driver software, which is interpreting electrical signals, which themselves are electrons, which at any given point in time are either on or off (1 or 0).

Doing this in an interpreted language only adds a couple more layers to the above abstraction stack.

As software engineers, our work is an abstraction (software) built on top of an abstraction (hardware) built on top of another abstraction (electricity). The sooner you come to the realization that your software will never be perfect, in any sense of the word, the sooner you will start producing better, high quality software.

But KYA, you ask, how is that possible?

If my software is supposed to do X, I should not tinker with it until not only can it do X, but also Y and Z. If delaying the shipment of my product is caused by any form of over-engineering or scope creep I have failed professionally. Extra features are great, but software at 100%+ in test that is never deployed is far more useless then the same software at 80% out there running. This principle is key in avoiding shelfware.

A direct correlation are the points made in this article in this discussion thread, our jobs are to develop [and ship] software. We're in the customer service business, we just happen to be coding. Unless you're in a research lab somewhere, you aren't being paid to program things.

---
Keep in mind that all software sucks and yours will suck considerably less. You're welcome.

4 Comments On This Entry

Page 1 of 1

Curtis Rutland Icon

06 November 2011 - 12:54 AM
Something only tangentially related, but I have to get it off my chest. Remember rule number one: "you are not your code."

Don't wrap your ego up in your programming. It doesn't make sense to. Your code isn't perfect. Ever. There's always something else it could do, or some better way to do it, or some other language that you could have made it more efficient with. Someone out there will always think they have a better way. Don't take it personally.

This is even more important on a help forum. When you come asking for advice, and someone criticizes your code and offers advice on something other than what you were asking for, don't get huffy or defensive. Consider it. Weigh the value of what they're suggesting and their level of experience with your own. Don't just take your ball and go home because someone didn't like your logic, and tried to help you fix it rather than helping you implement something fundamentally broken.

You are not your code.
8

trevster344 Icon

06 November 2011 - 09:22 AM
I often ask my dad if he's done programming(meaning for the day), but he always interprets it as the program being complete. Of course at this point I know the answer, and proudly he says "Son, I'm never done programming there is always something else I can do to it". So I definitely agree Curtis!
0

KYA Icon

06 November 2011 - 12:46 PM
Well said Curtis.
0

jon.kiparsky Icon

07 November 2011 - 08:22 AM

Quote

When you come asking for advice, and someone criticizes your code and offers advice on something other than what you were asking for, don't get huffy or defensive.


Right - if you ask for advice, and you get it, someone's done you a favor. Say 'thank you', first. Then you can do whatever you need to do with the advice, apply it or ask more questions about it or discard it, but 'thanks' is the best place to start.
1
Page 1 of 1

December 2014

S M T W T F S
 123456
78910111213
14151617181920
2122232425 26 27
28293031   

Tags

    Recent Entries

    Recent Comments

    Search My Blog

    3 user(s) viewing

    3 Guests
    0 member(s)
    0 anonymous member(s)