And you are here why?

You know how, when you turn on the tap, the water initially comes out all nice and smooth and neat and transparent? And then as the flow increases, things start going a little wonky? This is the difference between Laminar  and Turbulent  flow, between water that is coming out neatly, all lined up, and in layers, vs water that is irregular, chaotic, and mixing with itself all over the place. And yeah, there is very definitely an analogy to be made with organizations here. Take Laminar flow. Smooth, well-running, oiled, process-oriented, "everything in place" - nice adjectives to associate with your organization, right? It makes sense after all, the last thing you want is chaos all over the place, with stuff constantly breaking, nobody knowing what's going on, seventeen different ways of doing things, and so on. And I'm not here to disagree with this - you actually  do  want these characteristics in most (if not all!) of your internal systems, processes, and services....

/via Tomas Petricek

There is a special place in hell reserved for whoever came up with Open-Plan Offices.  I have yet to find  anyone  that likes working in them.  Or, for that matter, being involved with them - with the exception of those that decide that this, this  is the silver bullet that is going to " make us as cool as Facebook "

(yes it is a bad  idea...) / via @mshelton

/via Bubba Hines

You know, when you said  "Its a simple little patch, won't affect anything, don't worry about it! " Yeah, that one. Commit Strip is all over it

(#Erlang)  Here Lies Coder"          "pang"

Heck, any  kind of refactoring...

A Patriot Tab which I keep permanently plugged into my SSD Mac. - It k eeps my ElasticSearch/Cassandra instances and tests from killing the SSD

hat-tip Adam Rutkowski

Great articled on Sealed Abstract on this . Go read the whole thing - its long (10K words!), but completely absolutely worth it. The conclusion is fairly straightforward (and depressing) So here’s what you should remember: Javascript is too slow for mobile app use in 2013 (e.g., for photo editing etc.).   It’s slower than native code by about 5 It’s comparable to IE8 It’s slower than x86 C/C++ by about 50 It’s slower than server-side Java/Ruby/Python/C# by a factor of about 10 if your program fits in 35MB, and it degrades exponentially from there The most viable path for it to get faster is by pushing the hardware to desktop-level performance.  This might be viable long-term, but it’s looking like a pretty long wait. The language itself doesn’t seem to be getting faster these days, and people who are working on it are saying that with the current language and APIs, it will never be as fast as native code Garbage collection is exponentially bad in a ...

Seriously. You know what " Technical Debt " is, right? Ok, heres the (official?) Wikipedia definition   Technical debt   (also known as   design debt   or   code debt ) is a   neologistic   metaphor referring to the eventual consequences of poor or evolving   software architecture   and   software development   within a   codebase . The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. And in this - somewhat purist - sense, " Technical Debt " is absolutely valid. The problem arises in the way it is almost invariably used, viz., as an excuse to not do something. Herewith a simple exercise - t...

Long boring post about Java 9/10/... at The Register , but some fun things embedded in there nevertheless. “Java is not the new Cobol,” Ritter said. “I've seen analyst reports where Java is the new Cobol where it drifts off into insignificance but I don't believe it is that way.” which, of course, smacks of Bill Clinton's plaintive " The president is still relevant " line.  I mean, come on, you don't say stuff like that... “This requires more discussion, to make Java a true Object-Oriented language,” Ritter said of the potential move to OO. Which, of course, promptly causes furious head-scratching from the billions of java-dweebs out there who are thinking to themselves " Huh?  I thought it was OO? ".  Of course, there is the simultaneous snickering from all seventeen smalltalk developers out there saying "Well, d-uh. About time too! ". Fun times indeed :-) Note :  For what its worth, my opinion on OO/Java

Jeff Atwood has a writeup about listening to your community .  Its a great article, and worth perusing in its entirety, and broadly boils down to the following Most feedback is crap : However, 10% is awesome.  Filter it out, and use it! Stick to your mission : If you're building a car, build one.  If its a truck, build that.  But, for heavens sake, don't build a hybrid (Subaru Brat! W00t!) Be honest : Tell people what you will - and won't - do.  Feedback is critical, and immensely appreciated even if it is negative Listen well : Determine the underlying need in the requests.  Its not what they're asking for thats important, its what they actually need. Be there for the community : The very act of listening publicly, and interacting creates a virtuous feedback loop that immeasurably improves goodwill. That said, I'd add one additional item : You are not your user-base Seriously, this is one of the easiest traps to fall into - one where you ...

OK, some bugs are the developer's fault, but if you eliminate the n00bs and the idiots from the test demographic, then I stand by my statement. OK, fine, we'll also eliminate syntactical errors (you are using syntax checking in your development environment, aren't you?  If you aren't, go away.).  But that pretty much is it. I've used a plethora of languages and platforms - C, C++, erlang, java, objective-C, perl, python, ruby, and javascript (if you can call that a language.  And yes I'm joking.  Mostly.).  Its pretty much a best tool for the time and the place kind of existence, and AFAICRemember there has always been the persistent underlying frisson of fear , forever,  around bugs/errors.  And they all share one commonality. Errors are, always and every-time, considered to be a fault on the part of the developer. Pity you, the poor java developer. You begin by writing defensively. You absolutely infest your code with fun stuff li...

Edward A. Lee (of Ptolemy fame) is the Robert S. Pepper Distinguished Professor at U.C. Berkeley, and knows a thing or two about designing and building concurrent systems.  He also has a hate-hate relationship with Threads, as evidenced by my perusal of The Problem with Threads (Jan 2006).  For example Threads [...] are wildly non-deterministic  non-trivial multi-threaded programs are incomprehensible to humans we […] require that programmers of multi-threaded systems be insane. Were they sane, they could not understand their programs If we expect concurrent programming to be mainstream, and if we demand reliability and predictability from programs, then we must discard threads as a programming model  And there is more, oh so much more.  Just read the whole thing - its wickedly entertaining, and makes its points with no small amount of wit and humor.  Herewith a quick look at the points made in the paper. Note : All of the below applies to T...

I could get into the whole definition of Quality, and go off on a digression about the false dichotomy of separating Truth And Quality, about the need to fuse Rationality and Romanticism, and then end up telling you to Just Go Read Zen and the Art of Motorcycle Maintenance .  Mind you, that would be my attempt at ignoring the original question (See?  Thats why I could never be a politician!), and we can't have that, can we? Back to Software Quality - the underlying issue in defining it is that it really depends on where you are standing.  Lets just assume that you know what you care about vis-a-vis methodology, i.e., you want modular code, written in erlang, using Strong OTP Principles, etc, etc. etc.   At this point, you should probably look for Software Quality based on the people involved.  i.e., if you have quality people, you'll probably have quality software.   ( Joel Spolsky has a great writeup on this, which I am absolutely ...

Rewrite after the third update Corollary For sure, yea and most definitely so after the third bugfix! The third time you update a piece of code with a new feature or new functionality, take a look at the module, and see whether it can be re-written better, differently, simpler, with more documentation, etc. Odds are that it can. Odds are that the time you take to do the rewrite will be more than paid off the next time you edit this code. Mind you, if you've been updating the code due to bug-fixes, there is something profoundly wrong with what you are doing, so take a long hard look at not just the module but everything else. Is there a logical/semantic issue here? Is the code being rushed into production? Are the requirements bad? Do you need help? (and so on, and so forth...)