The Duct Tape Architect | Hacker News Reader

The Duct Tape Architect

cubeia.com

134 pointsFeeble25 comments

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.

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.

> 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.

Unfortunately, it is very easy to see the cost of the new SSD, not so in term of manpower. I would not be surprised if many companies will choose the "more enginering" part because the bureaucracy has made this kind of tradeoff impossible to make.

This. The development department is usually a fixed cost and budgeted for while new purchases are not. SSD:s were actually quite expensive at the time, I think it cost about 10k USD or something.

Interesting.... I may be the edge case, but in my experience, the tendency is usually for the boss to be more comfortable spending money for a solution that will solve the money than burning developer time on a project that may or may not fix the problem and mare or may not be on time.

That works if you have a boss who is competent and if you don't work in big companies. That's exactly the kind of things which make small companies inherently more efficient, IMO.

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?

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.

Cheers. It is not that I had to be convinced so much that I was surprised on how much different approaches we ended up with from the initial discussions, and how well they fitted the bill in the end =)

"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.

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

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.

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.

I agree though, but as usual, there is limited focus in the company and not rocking that boat meant more time spent elsewhere. However, it does feel a bit... wasteful.

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.

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?

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

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.

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

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.

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"

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

Good reminder to line up decisions against hard dollars.

This article needs to be refactored.

Reply on news.ycombinator.com