1. Raestloz's Avatar
    It's been a long running gag here that everything needs an option. "Just give us an option" you'd say "what's so hard about it? You just flip the switch on/off, right?"

    Well, it's not always like that.

    The basic concept of programming

    While it is true that, in the virtual world made up of code, everything is possible (ranging from staring a wall all the way to generating a living world god-style), it's not always possible - or rather, viable - to have options for everything, especially for on-going-development programs.

    To understand why it's that way, consider that programming is merely a means to an end: you want A to happen, so you code something to make A happen. HOW you achieve A is generally not important, it's the end result that matters. The program can go launch a space rocket from Earth to Pluto and all the way to Andromeda and back, reciting every dialogue ever in Dr. Who in the process and it won't matter, as long as A is achieved.

    But the tricky part in programming is actually not whether A is achieved, the trickiest part is in HOW to achieve A. Depending on how you do it, the future of the program can very well be set in stone.

    To understand this concept, imagine that you have a glass of water, and a program that can make water disappear from it.

    You want the water to disappear from that glass. The program has multiple ways to achieve this:
    1. Drink the water
    2. Pour the water to the floor
    3. Pour the water into another container.

    All of those has advantages and disadvantages: Pouring the water to the floor is very fast and gets the job done, but leaves messy stains.
    Pouring the water into another container leaves you with a garbage, but still relatively fast
    Drinking the water leaves absolutely no garbage whatsoever and is very clean, but is the slowest method.

    As you can see, all three do achieve the desired result: the glass is empty now. But wait, right after that, you changed your mind: now you want the water back. What can the program do? It's dictated by what it did before:
    1. If it drank the water, there's no way to get the water back
    2. If it poured the water to the floor, the water can be salvaged, but is hard to do and messy
    3. If it poured the water to another container, it can simply pour the water back to the glass.

    As you can see, the fastest method is easier for the original request, but makes things hard later. The cleanest method blocks any other development, while the slowest method actually makes things easy later on.

    Armed with foresight, you'd choose to just pour the water to another container, but developers do not have foresight, they have a goal to achieve, and they program to achieve that goal. Programs need to be optimized to improve customer satisfaction, but as you can see from the example above, optimizing a program for one particular case can make it difficult to do another job later on when the program needs to have another feature.

    Obviously, programs usually get repeated input, so updating a program won't just break it to the point of no return like that, but the example above is extreme simplification. The way you program something may very well make it difficult to have options for that, or down the road.

    I'm not saying that we should not have options for everything, but we need to ease ourselves before saying "why not JUST add an option?"

    Z10 STL100-1/
    Azensun likes this.
    02-13-14 12:32 AM
  2. Branta's Avatar
    That is a great example for why late-demand feature creep causes delay and problems.
    02-13-14 03:55 AM

Similar Threads

  1. Wikipedia for BlackBerry!
    By 1guitarguy in forum General BlackBerry Discussion
    Replies: 3
    Last Post: 04-03-14, 05:15 AM
  2. Trade Q10 for Z10?
    By manni1to in forum BlackBerry Z10
    Replies: 14
    Last Post: 02-14-14, 01:24 AM
  3. Contact changing not saved
    By anischab in forum BlackBerry Z10
    Replies: 6
    Last Post: 02-13-14, 11:32 AM