

The Duct Tape Architect - Feeble
http://www.cubeia.com/index.php/blog/archives/140

======
jpablo
I would choose the SSD every time over a method that requires doing a lot of
consulting and engineering of the current system like Sharding.

Why spend a lot of time and work when a simple hardware upgrade will work ?

And you are deluding yourself if you think that the sharding model you are
going to implement is not "only buying you time" and you will have to do
additional engineering over time if you keep growing.

~~~
nostrademons
It depends how many SSDs you need. If you have _one_ hard disk that needs to
be upgraded to an SSD, do that instead of spending developer time on it.
However, if you have _thousands_ of disks that would all need to be upgraded
to SSDs to save your 20%, it might be worth looking into software
optimization.

Same for manual cleanups and stuff. If you need to fix half a dozen source
files, just wince and do it manually. If you need to fix thousands of source
files, it's probably time to write a parser & refactoring browser and then use
that.

~~~
wazoox
> However, if you have thousands of disks that would all

> need to be upgraded to SSDs to save your 20%, it might be

> worth looking into software optimization.

However the margin is still quite high. I've replaced twice big EMC SAN arrays
with 8 SSDs, and the performance gain was 300 to 400% (different customers,
different applications).

SSDs envelope is usually quite narrow, but if you hit the sweet spot it's such
a game changer than it beats everything else.

------
digitallogic
I'm a little disconcerted that in each case it was other people that had to
convince the author of the alternative approaches given that the he has been
"doing software architectural work for a long time now".

Kudos for acknowledging the benefits of their approaches, but I feel like it's
the architect's responsibility to reconize the most cost effective solution
for the context at hand. How many problems aren't we hearing about that could
have been solved with a new network switch instead received an application
rewrite with an SOA architecture?

~~~
alextgordon
This initially struck me as well. However, it's important to note that this is
intentionally a 100% biased sample. By nature it only includes _two_ times he
got it wrong. For all we know, the other 998 times he got it right. Drawing
any meaningful conclusions is therefore impossible.

------
praptak
_"Besides, do you want to be the guy who calls them up and tell them and their
families that they are losing their jobs? And for what? Saving a buck after 7
years? We have a choke-full backlog to work on anyway."_

Not saying what they did was wrong but there's still the option of automating
those guys' tedious tasks and finding them something more useful to do.

~~~
VBprogrammer
I'd laugh if those Indonesian guys had found a way of automating it themselves
and spent their time doing something more useful!

~~~
mkramlich
They automated it by creating a script that pushed job requests to Amazon
Mechanical Turk, which were then carried out by other "developers" in China,
etc.

~~~
pavel_lishin
It would be amusing if the original developers got bored one evening, and
decided to spend some time on MT... and saw the very tasks they'd been
assigning their off-shore team there.

And then did them.

------
8ren
Please, Fredrik Johansson, can you add some more "Duct Tape Architect"
stories? It is a brilliant format, of the sensible, logical _everyman_
developer with whom we can all identify, being shown up by those familiar with
the intimate details of a specific situation. Love it, it is the universal
monomyth of the hero-developer.

------
igrekel
I don't really understand how adding a scheduler was that much of an effort.
Couldn't something based on cron work, the code from the Start button the
indonesians use is probably similar to what is necessary for that job. There
are certainly a few gotchas I have not thought of. Anyone has an idea?

~~~
Feeble
You have not seen their code base my friend. It was vile and nasty ;)

------
mirkules
Our company has clients that have different scalability needs. Whenever we
were faced with a bottleneck on one of our servers, my boss had a saying:
"Hardware is always cheaper than software."

I thought he was insane. But It's funny, it was almost always the case.
Throwing another server at the problem turned out to be way more cost-
effective than having to go back to engineering, spend 40 hours optimizing and
another 40 doing regression testing.

~~~
dedward
That works great if your application was designed to scale horizontally, or if
there is always a bigger server available.

------
slantyyz
This is a classic effectiveness (as Larry the Cable guy says, Git-R-Done) vs
efficiency (Git-R-Done faster/better!) discussion.

Ideally, you want effectiveness and efficiency. If you can't have both, you
need to be effective before you are efficient, as both of the author's
analogies make clear.

~~~
arethuza
I always understood that as:

1\. Make it work

2\. Make it right

3\. Make it fast

Sometimes only getting to 1. is "good enough"

~~~
mkramlich
yep. because 1A might yield "FU money!". If not, you have to do 2 because it
might not come til 2A. Or 3A.

------
famousactress
Good reminder to line up decisions against hard dollars.

------
J3L2404
This article needs to be refactored.

