Information Technology Blog

Posts Tagged ‘Thing’

 

The law of diminishing marginal returns

 

I recently had a bit of a debate with a technology consultant friend who knows I am huge on content and detail within project planning and the contracts that support a technology deal.   We found ourselves speaking about that principle of economics called the law of diminishing marginal returns.   His point was that for project owners who are in the midst of planning a new project—gathering requirements, fleshing out specifications, polling individual preferences, etc. —the law of diminishing marginal returns sets in much primeval than they realize.   The resources spent during the initial planning stages produce some hefty returns.   But soon after, spending the same amount of resources again, and the next time after that, will produce smaller and smaller chunks of benefit.   When you are caught up in a planning process, it is often difficult to refer the point at which your cost-benefit curve has begun to flatten.

 

What my friend was saying seemed plausible, and because I did not have any evidence to the contrary, I just accepted his theory.   Then I thought of a doable consequence of his theory, and I said, “You’re not going to go out and begin spreading this thought around the technology community, are you?”

 

Threatened evangelist

 

My fear was this.   Here was I, this evangelist of content and detail within apiece information technology project, and crossways the plateau was a fellow who could undermine the past and future progress of my mission by telling folks they actually need less planning and critical thinking for their technology projects and not more.    Project owners’ planning and thinking are, after all, what generate the content and detail I crave and have come to respect.

 

Well, we talked some more, and my friend added some clarification.   As it turns out, he was suggesting mainly that project owners not waste time and money planning what can't be planned effectively at a particular point in time.  Made sense.   I was still squirming, but now a bit relieved.

 

Obvious example

 

You have decided to use a staged or iterative approach for your next project.   You will purchase some off-the-shelf software and customize it a clean amount.   Phase 1 might involve extending a discrete element of existing functionality and then wiring up to a live database for some testing.

 

In this example, there is really no point to thinking through the details of Phases 2 through 5 or estimating costs within those phases, except in either case at a very high level, because:  1) unless Phase 1 is finished smoothly and with an acceptable cost, you will never get to the subsequent phases; and 2) you have not yet tested your assumptions about costing within Phase 1.   Indeed, you probably selected an iterative approach for this project because of your inability to plan your project effectively from begin to finish.   

 

Less obvious examples

           

My friend and I talked some more, and we moved beyond the obvious examples, the ones that are simple to accept.   My natural reaction was to resist any further extension of his theory because I knew he would be slicing closer and closer to the bone, threatening the very foundation of my evangelist mission.   However, sitting before me was a bright mortal and a clear thinker, with almost two decades of experience with technology.   I had to listen (nervously).   “When the student is ready to learn, the instructor will appear. ”    

 

Requirements gathering – A good thing, no doubt, and something the experts have been encouraging us to do more of over the last ten years.   “Insufficient stipulations development cited as leading cause of project failure. ”  When it comes to requirements, we have been led to believe that more is not enough.   Surely there is a point at which more stipulations are not helpful (and might even be detrimental), but the experts have not told us how to determine just when we have turned the corner.

 

Specifications development – Same story.   Develop specifications thoroughly now or risk project failure.   

 

User preferences – Same story.   Involve your users in your planning process.   Otherwise, “If you build it, they won’t come. ” 

 

We have heard so much preaching on these topics that apiece of us can rattle off a number of clichés for apiece topic.   The advice has been mostly good, but we are hammered with it by speaker after speaker, in article after article.

 

Reconciliation

 

As much as I resisted the flow of this discussion with my friend, I have to admit that what he was saying prefabricated perfect sense to me.   But now I had to find some way to reconcile two divergent concepts:  on the one hand, my long-held belief that more project planning and critical thinking should always be one’s aspiration, and on the other, my realization that you truly can have too much of a good thing.

 

Ultimately, I found the reconciliation I needed with just one insight.   It occurred to me that, with all of the speakers and literature out there telling us to engage in more ideal practices for our technology projects and more often, we have become conditioned to believe that more is not enough—in fact, because of the nature of the beast, more can never be enough.   We have been doing more and more, and the incremental improvements we have witnessed, together with the new articles we read, encourage us to keep doing more and more.   Of course, our intention is good, but when can we stop doing more?  When should we stop doing more?

 

It’s all relative

 

I think it all boils down to relativity—your relative sophistication as a technology buyer, and the relative nature of your particular project.   If you started heeding the experts’ advice many years ago, your approach to buying technology might be evenhandedly sophisticated by now.   You might be doing an appropriate level of planning for your projects, and maybe you occasionally do too much.   Other organizations are just now opening their eyes to a superior way, perhaps prompted by a current problematic project.  

 

Second, when enough is enough depends on your particular project.   Your goal is to plan effectively and thoroughly for all aspects of your project, but be mindful that your present need or capability to plan certain elements might not yet exist.   Further, even if you have the present need and capability to plan a certain aspect of your project, do not overdo it.   For example, do not continue to add more and more stipulations to your stipulations basket as if quantity were your only goal.

           

On this last point, remind yourself that requirements, specifications, individual preferences, and apiece other item on your project-planning list have at least one thing in common.   Once you have thought of them and cemented them into some spreadsheet, they have a way of hanging around for the duration of your planning process, and often through completion of your project.   Instead of inactivity to whack some of these hangers-on toward the end of a phase or at the end of your project (“backward creep” of scope or deliverables), attempt to prioritize them at an primeval stage of your project.   You will not even open Stipulations Container 2 until the high-priority stipulations in Container 1 have been fatigued (satisfied or deliberately discarded).   A prioritization approach could save you time, dollars and other resources.

 

Conclusion

           

For many of us, it might be ideal not to let go of our conditioned response to project planning and critical thinking—not just yet anyway.   The conditioning represents an overall positive motivation, its underlying purpose is producing results, and our technology procurement process, including its planning element, might still have plenty of room for improvement.   The more sophisticated technology buyers among us might want to place the brakes on the conditioned response a bit.  

 

Regardless of what camp you are in (and until further notice from the experts!), be at least mindful of the fact that there is such a thing as too much project planning.   I, for one, am now a believer.

 

 

 

 

 

 

© 2008 All rights reserved.  Nuckles Law Firm

Once each so often our customers are asking us how come on some websites our software is sold at a fraction of price or is even free. They further ask how come they have to pay for the software if they can download it for free.  Those questions are legitimate and deserve a separate article below.

Most of you have already seen favourite software brands and packages acquirable on certain websites such as Germany-based Rapidshare and the likes. The software is offered free of charge or for a nominal price with the labels “Nulled” or  “Software Name + keygen”, etc.  This essentially means that the software anti-piracy mechanisms have been illegally tampered with or re-engineered. This is a common plague that the entire software industry is suffering from to a certain degree, and the more favourite the software becomes, the more frequently its defenses are being tested (sometimes successfully).

Many potential customers share one or more of the six common myths about the use of nulled scripts. Let us take a closer look at those myths:

Myth #1.The software manufacturers can’t really find me, John Doe, since the World wide web is soo huge, right?

Truth: Wrong. Most script manufacturers use one or more techniques to trace locations where active script duplicates are installed. Many of such techniques are disabled by reverse engineering, some still remain active or are remotely activated by the manufacturer (which usually kills the software or maybe even something else).

Also, it is not all that difficult to carry out a sophisticated search and find illegal duplicates scattered all over the world. A Google Labs creation, Google Code Search, is an awesome tool just for that.

Myth #2. They won’t bother to spend time on chasing me around.

Truth: Only some won’t. Others will track you down, and if you happen to be in an appropriate jurisdiction, they will sue you and take away your money, business and reputation. Others might be too small or care less if you are using their product without paying you, but at some point things can change all too quickly.

In many countries, the software manufacturers won’t chase you, but the police will. Messing about with OPIP (Other People’s Intellectual Property) in Europe will most likely get you into serious trouble with the law.

Myth #3.  It’s the same software as its paid version, but it’s free, so why not use the cracked one I can download for free?

Truth:  The software is not always working the same was as its paid equivalent. It might be a cracked copy of a demo with limited functionality, could be poorly cracked and won’t work as intended, might demand some important code or features disabled or improperly reengineered by crackers. Software found on Rapidshare either for free or for a fraction of its real price will most likely be an old noncurrent version discontinued a long time ago, or full of manufacturer bugs, or no longer supported, or might be a trial/demo version with limited capabilities. You are also likely to download yourself a trojan or a virus or two along with the crack. One thing you can count on, and that is, you will NOT get any help, updates, or support from the manufacturer.

Myth #4. The software manufacturer will probably support its software anyway because they sell thousands and thousands copies, so how would they know if that’s a legit copy or not?

Truth:  They will most likely know. Don’t count on them using cheap outsourced workforce in the customer relations who doesn’t care about this and just worried about getting through the day. Usually a cursory inspection by the employee will reveal that your copy is a fake, and then all hell will break loose around your website, including a doable visit of police. IP’s are so simple to trace these days after all…

Myth #5. A nulled version is no different from the legit version except that the defense algorithms are disabled.

Truth:  Would not count on that. Reverse engineering is a process that recreates the design logic of the software and its functions. As a result, you might receive hotwired software that might have some or several key or minor functions bypassed.

Moreover, you’re stuck with this version because developers often change the defense logic and any subsequent upgrades might not be possible, or take too much effort to be prefabricated operational (remember, you don’t have support, right?).

Myth #6. I am saving a lot of money AND I am fighting for the digitally equal society since I am not ready to pay those fat pigs who ask so much for their software.

Truth:  Yes, you might be saving some upfront money. The money will not go to fat pigs’ deep pockets. Because of that, those notorious software tycoons will have less money to invest in further product development, including paying their staff (which makes up the bulk of the costs as PC’s are cheap as dirt these days).

As a result, less money for software engineers, support and marketing specialists, which means more potential competition on the market for you and your work/projects.

The whole truth is that the fat pigs will most likely continue charging the same amount of money for their products that are usually superior than their GNU/GPL equivalents, or will increase prices to recover losses from bad sales.

If you are fighting for the digital equality, simply get yourself a GNU/GPL equivalent of the paid script and you’ll be all good to go.

The above myths show that the only celebration seriously affected by the illegal use of pirated software will most likely be you. You’ll strip yourself of support, help, and product updates, get unwanted attention from the law and might risk a major lawsuit you don’t have a chance to win in the event your project turns out to be a large success.  In the process, you will waste more money and time on trying to do everything yourself. Is all of that really worth it?