Is it better to
-
Is it better to start late and catch up, or start early and be caught?
Starting late is my preference. Planning more, seeing which direction others go, etc. If you start early, haring off in some direction, and everyone else chooses a different path, you may have to backtrack to catch up to them. Just yesterday, I had this sort of thing in mind again. I saw some Subaru Outbacks on the road and thought again about how popular they are and how unpopular the AMC Eagle was when it was released. AMC started too early, the market wasn't ready for an AWD sedan/hatchback thingy yet. While Subaru was able to see the AMC Eagle as a case study and learn from its failure. All too often we see a company having some idea for a product and saying "we need to be first to market" -- that tactic fails more often than it succeeds. The product is often poorly designed/implemented and obviously rushed. Whereas the competitors will see how the market reacts and can make a wiser, more reasoned plan.
-
Starting late is my preference. Planning more, seeing which direction others go, etc. If you start early, haring off in some direction, and everyone else chooses a different path, you may have to backtrack to catch up to them. Just yesterday, I had this sort of thing in mind again. I saw some Subaru Outbacks on the road and thought again about how popular they are and how unpopular the AMC Eagle was when it was released. AMC started too early, the market wasn't ready for an AWD sedan/hatchback thingy yet. While Subaru was able to see the AMC Eagle as a case study and learn from its failure. All too often we see a company having some idea for a product and saying "we need to be first to market" -- that tactic fails more often than it succeeds. The product is often poorly designed/implemented and obviously rushed. Whereas the competitors will see how the market reacts and can make a wiser, more reasoned plan.
Good thing your preference is not followed by everyone. Otherwise we'd still be pushing square wheels while everyone waits to see if the market is ripe for round ones. ;P
Mircea
-
Is it better to start late and catch up, or start early and be caught?
Never start, don't be caught. ;)
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
Is it better to start late and catch up, or start early and be caught?
-
Is it better to start late and catch up, or start early and be caught?
IOW, is it better to request permission or to request forgiveness?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
IOW, is it better to request permission or to request forgiveness?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
I usually find requesting forgiveness best. Especially when it is my wife! :-D
-
IOW, is it better to request permission or to request forgiveness?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
It is easier to request forgiveness, not better. "It is often easier to ask for forgiveness than to ask for permission." -- Grace Hopper
-
Is it better to start late and catch up, or start early and be caught?
-
It is easier to request forgiveness, not better. "It is often easier to ask for forgiveness than to ask for permission." -- Grace Hopper
Sometimes, it can be better to ask for forgiveness. When entering a new job many years ago, I was given the task to write a GUI for a distributed debugger - extremely fancy for its time, but strictly command line oriented. The company had no experience whatsoever with GUIs (some eccentrics were using emacs for editing source code, but that was the limit of GUIs for them). So I was hired to create a Windows-like UI of mice and men(ues), updating the display immediately when something happened etc. etc. The major problem was that I was given nothing but the existing command line interface to interact with the debugger core, no API. The CLI was a conventional command-output one: You ask for the value of some entity, and it is printed on the console. To keep updated e.g. the state display of all treads in all machines in the network, to make it appear as if display updates were event driven, I had to poll all displayed values continuously. I started out with polling/updating visible values only, but customers complained: When they pulled a large table to the front, they had to wait for the update. The table might well contain five thousand threads from a dozen nodes, sorted on the thread state value - that update was nothing like 'immediate'. So I had to change that to continuously polling all values of all data structures on the screen, whether visible or not. The attitude towards performance was 'Throw in some more iron'. But there was a second problem: Before I was hired, the management had decided that this GUI was to be implemented in Tcl/Tk. They had read that Tcl/Tk is a great tool for making GUIs (but it had never been tried out before in other projects). This decision was carved in stone and could not be argued. This was before Tck/Tk had any sort of (byte) compiler; if you iterated a tight loop a thousand times, the loop body was parsed from source code a thousand times. Running busy loop polling on several dozen tables, each of hundreds or thousands of entries, having to parse the output from a CLI interface, is not the thing you would do in a language every source line anew every time it was executed. It also follows that even the most obvious syntax errors were detected until you attempted to execute that line, and the system crashed. I begged for permission to at least partially change the implementation to something else. It was denied. As Tcl programmers know, you can write functions in C, compile them and link them to your TCL process with a plugin
-
Is it better to start late and catch up, or start early and be caught?
-
Starting late is my preference. Planning more, seeing which direction others go, etc. If you start early, haring off in some direction, and everyone else chooses a different path, you may have to backtrack to catch up to them. Just yesterday, I had this sort of thing in mind again. I saw some Subaru Outbacks on the road and thought again about how popular they are and how unpopular the AMC Eagle was when it was released. AMC started too early, the market wasn't ready for an AWD sedan/hatchback thingy yet. While Subaru was able to see the AMC Eagle as a case study and learn from its failure. All too often we see a company having some idea for a product and saying "we need to be first to market" -- that tactic fails more often than it succeeds. The product is often poorly designed/implemented and obviously rushed. Whereas the competitors will see how the market reacts and can make a wiser, more reasoned plan.
A story from many moons ago... think mainframes, IBM and the seven dwarves... A manager from one of the dwarves, speaking about the introduction of new technology. Whoever introduces it first gets the glory. Whoever comes third gets it right.
Why do we always come second?Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Is it better to start late and catch up, or start early and be caught?
-
Is it better to start late and catch up, or start early and be caught?
