tradeoffs


Fallacies of massively distributed computing

Posted on April 29th, by Arnon Rotem-Gal-Oz in Big Data, Blog, Featured Posts. 5 comments

In the last few years, we see the advent of highly distributed systems. Systems that have clusters with lots of servers are no longer the sole realm of the googles’ and facebooks’ of the world and we begin to see multi-node and big data systems in enterprises. e.g. I don’t think a company such as Nice (the company I work for) would release an hadoop based analytics platform and solutions, something we did just last week, 5-6 years ago.

So now that large(r) clusters are more prevalent, I thought it would be a good time to reflect on the fallacies of distributed computing and how/if they are relevant; should they be changed.
If you don’t know about the fallacies you can see the list and read the article I wrote about them at the link mentioned above. In a few words … Read More »

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Buffer this pageShare on RedditShare on StumbleUponEmail this to someone

Make technical debt explicit

Posted on August 7th, by Arnon Rotem-Gal-Oz in Blog. 6 comments

This is a rehash of a topic I posted about back in 2008 but it is just as relevant today.

When you work towards a release or some other looming milestone. There’s that  urge to leave stuff behind, cut some corners – you know, just a wee bit, no harm done – so we can ship the damn thing already. Mostly you’d fight that urge. But sometimes you’d want to make a conscious choice to make a shortcut because, well,  sometime delivery is more important

A little drop in quality in a single piece of code will not do much harm…for a while. There are, however, two problems with going this approach. One is that it is a slippery slope, i.e. it is probably not just one piece of code that gets this treatment in your code base. The second problem is … Read More »

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Buffer this pageShare on RedditShare on StumbleUponEmail this to someone


Evolving Architectures – Part III starting out

Posted on May 17th, by Arnon Rotem-Gal-Oz in Agile Architecture, Blog, Featured Posts. No Comments

Before we talk about the what/how let’s do a quick recap on the why we’re here:

Architecture is important to software projects
Architecture and agile have some conflicting forces that needs to be reconciled  (e.g. up-front work, hard to change vs. delivering business value quickly and embracing change)
design can be emergent but architectures can’t and  must be grown instead

Another  important point to remember is that sometimes you can get away with it. By “get away with it” I mean you can make 1 day or less design session opt for an off-the-shelf architecture, usually that also means choosing a product (e.g. Rails or Django) and it would be good enough for your project. This is usually true for small project or for projects which are ver/y familiar (and thus rather predictive and for the most part can be handled by waterfall processes).

If your project … Read More »

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Buffer this pageShare on RedditShare on StumbleUponEmail this to someone

SAF – Evaluation part II – the “Formal Methods”

Posted on May 11th, by Arnon Rotem-Gal-Oz in SAF. No Comments

Onthe previous post on architecture evaluation  I talked about evaluating a candidate architecture in code. This post is dedicated to evaluation on paper.

I remember one system I was working on, I was keen on making the architecture asynchronous and message oriented (it was all circa 2001 by the way) However, I was new on the team and my role (as the project’s architect) wasn’t well defined so I had to do many compromises and get wide acceptance in order to get anything going forward. We set a team to try to come up with a suitable architecture, since each of the team members had his/her own experience we came out of these meeting with more than 20 (!) different candidate architectures (actually there were fewer architecture variations but they were multiplied by the possible technology mappings). Trying to decide which was … Read More »

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Buffer this pageShare on RedditShare on StumbleUponEmail this to someone