Quote:The C++ standard recommends limits for various language constructs.

That's funny. Microsoft's C++ standard seems to be a different one than mine, because mine says:

Quote:Because computers are finite, C++ implementations are inevitably limited in the size of the programs they can successfully process. Every implementation shall document those limitations where known. This documentation may cite fixed limits where they exist, say how to compute variable limits as a function of available resources, or say that fixed limits do not exist or are unknown.
The limits may constrain quantities that include those described below or others. The bracketed number following each quantity is recommended as the minimum for that quantity.
(emphasis added)

I mean, those are different things, aren't they? Or maybe they're reading it differently... :-)

Quote:Original post by nobodynews

Quote:Original post by Kylotan

Sometimes, getting the crappy solution up and running and using whichever ugly methods you need to get it working is the only way to guarantee the business will be around long enough to write the decent version.

I remember hearing a decent analogy (I'm probably remembering it wrong; I can't find a reference to it) about how code quality is something like taking out a bank loan. If the original code is like your debt then fixing the code is like paying off the debt. Sometimes writing code that is of low quality is necessary to start off a business, but unless that code is never updated some effort should be placed into gradually fixing it over time.

People often gripe at overpaid consultants who write crappy code.

But look at it this way.

A $FINANCIAL_INSTITUTION needs some $UTILITY software to run on monday, at 8:00. Every second, this software makes thousands of dollars.

Now you have two programmers. One that says: "I can fix it properly, it will take 6 hours", and the other who says:"It will be up and running at 8:00".

The proper fix will cost the bank $21 million and more. The just-in-time crappy fix will cost the bank $2000 (the price of consultant).

Does proper fix make sense? Let's say that you need to hire this consultant every single day for 5 years. That comes down to only $3 million.

eBay handles $1500-worth of listings every second. Can you really take 1 year off to "properly" rewrite that system?

Simply put - the proper fix will never *ever* pay for itself. Especially since it will still require feature updates, and it will still show bugs, and it will still show problems.

Know your business. Know the finances. It really isn't as easy as assuming a dogmatic approach that proper code, superb design and long-term benefits are better. Sometimes the market simply cannot pay for them, much to the dismay of the programmers. Myth says, that 1 line of code costs NASA $1000. If that is the way to go, can you build your FOSS forum software this way and finance it through support contracts? Should eBay use this methodology? The have 3.3 MLOC. The cost of such software would exceed the yearly income of most countries.

A relevant read about Waterworld syndrome.

Quote:Original post by Antheus

Quote:Original post by nobodynews

Quote:Original post by Kylotan

Sometimes, getting the crappy solution up and running and using whichever ugly methods you need to get it working is the only way to guarantee the business will be around long enough to write the decent version.

I remember hearing a decent analogy (I'm probably remembering it wrong; I can't find a reference to it) about how code quality is something like taking out a bank loan. If the original code is like your debt then fixing the code is like paying off the debt. Sometimes writing code that is of low quality is necessary to start off a business, but unless that code is never updated some effort should be placed into gradually fixing it over time.

People often gripe at overpaid consultants who write crappy code.

But look at it this way.

A $FINANCIAL_INSTITUTION needs some $UTILITY software to run on monday, at 8:00. Every second, this software makes thousands of dollars.

Now you have two programmers. One that says: "I can fix it properly, it will take 6 hours", and the other who says:"It will be up and running at 8:00".

The proper fix will cost the bank $21 million and more. The just-in-time crappy fix will cost the bank $2000 (the price of consultant).

Does proper fix make sense? Let's say that you need to hire this consultant every single day for 5 years. That comes down to only $3 million.

eBay handles $1500-worth of listings every second. Can you really take 1 year off to "properly" rewrite that system?

Simply put - the proper fix will never *ever* pay for itself. Especially since it will still require feature updates, and it will still show bugs, and it will still show problems.

Know your business. Know the finances. It really isn't as easy as assuming a dogmatic approach that proper code, superb design and long-term benefits are better. Sometimes the market simply cannot pay for them, much to the dismay of the programmers. Myth says, that 1 line of code costs NASA $1000. If that is the way to go, can you build your FOSS forum software this way and finance it through support contracts? Should eBay use this methodology? The have 3.3 MLOC. The cost of such software would exceed the yearly income of most countries.

A relevant read about Waterworld syndrome.

[idealist]
As I'm sure you're well aware: a person can be both financially conscious and technically competent. A "good" programmer can can make quick progress without utterly crippling the software for the future.

The coder that would get you in this sort of quandary is a liability, and a good financial mind should be able to see that that costs money too.
[/idealist]

Quote:Original post by Antheus
Know your business. Know the finances. It really isn't as easy as assuming a dogmatic approach that proper code, superb design and long-term benefits are better.

Equally well a dogmatic approach to save as much money now any way possible isn't usually better. The pages of the Daily WTF are filled with examples of what happens when you get a 'consultant' to do a few quick fixes. My impression is that the people who make business decisions aren't often on the ball on what the final costs will be. For example, the 'traditional' way of producing software, design-implement-test, has been shown to be more costly than maintaining good quality of code from the start, mainly because of testing requiring more time in the end.

Quote:Original post by SnotBob My impression is that the people who make business decisions aren't often on the ball on what the final costs will be.

Well, with eBay, you have hard numbers. They facilitate over $1500 worth of listings per second at 99.94% up-time.

You can do the math now of what it would take to update the codebase of 6 MLOC and 100 kLOC produced each week.

I'm not talking about idealistic or dogmatic approach. I'm talking about very hard numbers from the presentation.

Can you produce such software which will scale with the exponential growth presented that will hold for next 5/10/15 years? Can you do that by *reducing* the cost of this development? By still allowing features to be added on weekly schedule? And including the cost of migration, training? Supporting both versions at the same time? And still solving all the, at present time, unknown features that will arise during this time? And still allow 300 features to be added each week?

If so, then eBay has a job for you. A job that will write history and leave a mark on software development, while making you rich, famous and influential at the same time.

eBay is not a software company. They don't develop software, they don't make money from it. Software and hardware they run is the facilitator for their real business. Auction houses have existed for centuries. All of this is used merely to improve the process.

Quote:Original post by Antheus
Can you produce such software which will scale with the exponential growth presented that will hold for next 5/10/15 years? Can you do that by *reducing* the cost of this development? By still allowing features to be added on weekly schedule? And including the cost of migration, training? Supporting both versions at the same time? And still solving all the, at present time, unknown features that will arise during this time? And still allow 300 features to be added each week?

Didn't they do just about that when they rewrote their system? Perhaps they decided to adopt better practices so that there wouldn't be a need for that in the future?

Quote:Original post by SnotBob

Didn't they do just about that when they rewrote their system? Perhaps they decided to adopt better practices so that there wouldn't be a need for that in the future?

Read through the presentation, the choices are clearly presented. They had to rewrite it when they reached the limits of current architecture. It doesn't matter why they had so many methods, the system as a whole didn't scale anymore.

It started as a weekend project.

Later, they assembled third party solutions for everything.

These in turn enabled them to grow the business, up to the point where they exceeded the limits of that software.

At that point, they ran into lack of third-party solutions, so as the only way to scale beyond that, they implemented their own, custom solution.

But they did not, from day one, they leveraged existing solutions and proven software.

This is where common mistake lies. Software needs to perform some crucial function to be commercially successful. It's not software that generates revenue. As such, any excessive investment into software where it's not needed is often the reason for failure.

Note that none of this says anything about code quality. So they have more methods than compiler can handle. I'm pretty certain that they've heard of refactoring.

But the important thing is that they understood where the value comes from. eBay could not have been started by a geek. They'd spend 5 years building that ultra-scalable, custom-optimized, assembly-based web site.

And this is where the argument for feature-first-optimize-second comes from.

eBay will reach limits no matter how superb their solutions are. And given exponential growth, the difference between best and cheapest solution will likely be one week or two, while the effective price difference between the two will a factor of 10 or even a 100.

How many refuse to use std classes because they're slow. Just like with eBay - some projects really did reach the limits, so they went for custom version. But most simply hear about their problems, and assume they will apply to their project as well.

Let's say you're setting up an auction site yourself. You have no customers, no money, and no real employees. Is the proper way to go about it to look at eBay, and build a data center around 6 MLOC custom code, 2000 servers and Oracle license?

Or will a simple set of Python scripts do, until you reach its limits? How many people would say that Java is slow, and it could never be used for anything serious?

Knowing your project and your business is the key here. And such real life experiences are an incredibly valuable lesson to learn for anything hoping to make money out of software (or better yet, making money, but using software to expedite the process).