Author Responds
Thanks for all of the thoughtful feedback on Optimization - the right way, the wrong way and the highway. :-}
Optimization only where and when it is needed. That's the clear message you send.
Thanks,
BillN
5 publicly visible posts • joined 21 Nov 2006
Parallel programming is tough and will remain so, but it need not be one step short of impossible.
One of the keys to good parallel programs is the decomposition of the job into tasks which perform independent (or close to that) operations. The highest level of this needs to be done at the design stage.
Multitasking happens at two scales - the large individual tasks and the small steps that make up a task. In many cases, working at the task level is enough for effective parallel programming, but where individual tasks are large, they may need to be done in parallel steps, essentially a micro tasking.
However, micro tasking steps runs a danger of increasing complexity and overhead. So the task level parallel work will require design level choices, while the step level parallelism will need checking and testing for overhead. If the steps are so small that parallel code is a 50% overhead, the extra complexity will probably not pay useful dividends.
Ultimately, if task level parallelism still can't handle the workload, the best answer may be splitting the workload and running multiple copies of the whole program, essentially segmenting the workload rather than increasing the internal level of parallel programming.
We already do this in multiple system web servers or file servers as Akami uses. But the same segmentation and replicatiion approach could be a better answer than trying to increase parallel operations at the micro level because of overhead.
Being an old QA hack, I notice that the guarantees, good in themselves, come without defined *quality* standards.
While the implied standards would be 'Does the job' or similar statement, the lack of any specifics would make me (as a customer) quite uncomfortable. I can easily see an exaggerated situation where the software meets the startup requirements, but fails under additional use shortly thereafter.
So how does a customer specify quality and performance requirements, and how does the vendor verify that such requirements are met?
Delivery guarantees are a good start, but I'd be happier with a quality guarantee and worry less about slipped delivery. Late deliveries can be lived with, up to a point, but poor quality on an operational system can be a disaster.
Let's make sure we have the emphasis on the right component.
BillN
"The great thing about Standards is that there are so many of them."
The good and bad news all in one sentence. But Architecture is the real issue here, and it too suffers the problem of standards.
Architecture may be more important than standards. It sets the playing field for a set of applications that (are supposed to) accomplish a specific set of purposes. But the conflict in architecture design arrives when the desire for clear limits to the design space confronts the need for future flexability. Often times the future flexability wins out and the architecture becomes ill defined and less than useful.
This is a bad approach 90% of the time. The key to clean application design and implementation is a clear set of limits, not something that looks like an amoeba.
The best way I have to convey my view of how this should be done is to list the best and worst ways to design:
1. The all inclusive design: Design is finished when you can no longer add any features, AKA 'Kitchen Sink' design.
2. The exclusive design: Design is done when you can no longer take anything away, AKA the Einstein design criterion.
Note that #1 is Microsoft's design philosophy, and it gives us products like Word, which will do almost anything you want after a few years of training and experience. My personal selection, having tried both when I was younger, is #2.
Architecture defines the playing field for systems, and it should follow the principle in #2 for almost all systems. It is only where systems are probing the boundaries, experimenting with approaches, that approach #1 is useful, and even there well defined boundaries should exist if only to limit the time spent in marginal areas.
In both cases, experience and critical analysis of the purpose for the system should be your ultimate guide. The closer you can come to a limited, well defined playing field, #2, the more stable and reliable will be the product.
BillN
I suspect the takeup for this item will not be great.
Why? It's simple - developers are at the bottom of the food chain, especially as they are seen as an expense item, not an investment (by most shops).
Most places, and I've worked in a number, put their faith in more people and fewer systems. The potential productivity payoff for a big virtual development, and double that for a QA environment, is very hard to demonstrate on paper.
And therein lies the rub. In order to maximize productivity with a big virtual system, the system also needs to run some software that keeps the whole development process organized from inspiration to delivery.
It will require training, another expense, ongoing education, ditto, and run into the rock wall that is the mindset of most developers - resistance to change. Essentially "I already know how to program, so why do I have to learn this stuff?" attitude.
There will be exceptions, and those exceptions will slowly seed the mindset of developers with new ideas. Over time, say five years, the idea will gain strength *if* the first set of installs works well.
Yes, it could work. But I'd rather bet on the leading apprentice jockey to place than this revolution to succeed, because it really requires revoltionary changes in the developer environment and mindset.
BillN