John Esposito

I'm also far from expert re. networking tech. The simple idea I was trying to compress (probably not very well) is:

1. Packet-switching keeps a given message decoupled from a dedicated channel on the network. So the sender and receiver don't need to worry about anything beyond acknowledgment of receipt. This is the first abstraction, and is not hierarchical in itself.

2. On the Internet, the full set of actual channels used to transmit the message doesn't need to be known to any given sender or receiver. In a 'network of networks', decisions can be made relatively locally. This is the second, 'hierarchical' abstraction.

You probably know that much already. The interesting magic is in the way the Internet avoids O(n) connectivity. Much of this magic is in implementations of BGP (border gateway protocol). For me this was a good intro: https://www.researchgate.net/publication/327645872_Introduction_to_BGP

Some key findings are now available here https://dzone.com/trendreports/edge-computing-and-iot

..with additional analysis to trickle out over the next few months.

Great list. Also consider The C Programming Language and probably Elements of Programming, although I haven't read all of the latter (even though it's short).

Yes, additional examples would be superfluous -- I agree that inheritance and other kinds of hidden complexity/epicycles built into OOP lead to huge loads of programmer-brain, compile-time, and runtime overhead.

You're going somewhere new and interesting with that 50% number. I'm sure that percent varies by domain (as well as specific codebase). When you're weighing trade-offs in 'the real world', you always do have some kind of number in mind..but probably not something easy to measure empirically, exactly.

For me, irresponsibly generalizing, I'd say the percent of times a pure function is easier in the long run is well over 50. I think I'm subconsciously adding weights for number and 'hardness' of system boundaries, projected longevity of codebase, guesses at likelihood and type of later modifications, imagined familiarity with codebase of future developers?...a lot of things you can't know until after the fact, but which you have to imagine in order to run a good optimization function in your head. It would be interesting to get a whole bunch of developers' subjective guesses on 'how often does it turn out that, when you can choose between a functional or an OO approach, the functional approach turns out to be more maintainable'..and see how much this is steered by things like available tooling...

I agree that boilerplate is ugly, Java verbosity is ugly, and most OO-heavy code I've seen in client codebases is flabby and brittle. I also agree that the lambda calculus is basically zero-overhead, which is awesome. And I also agree that algebraic, type-oriented programming (e.g. Haskell) makes reasoning about program execution trivial, compared with OOP.

But let's distinguish (a) programming as inference-pipelining from (b) programming as theory-building, and let's focus on one particular construct: the anonymous function itself. (I take 'anonymous function' to be the same as a pure 'lambda function' in Church's sense: just a mapping that derives from another mapping ad infinitum.)

As a way to avoid overhead within the inference pipeline, the lambda is superb. But as a way to capture a domain, to precisify knowledge about a domain -- that is, to build a theory -- anonymous functions are not so great. Yes, throwing everything into hilariously over-the-top 'agent names' like SomeLongNameForDoingAThingAsVerbFormIfier is ridiculous, flabby, and stupid, from the point of view of the inference pipeline. Yay monads.

But as a way to precisify knowledge about a domain, (1) applying a (computationally unnecessary) name always adds interpretive information, and (2) 'hypostasizing' an action (i.e. avoiding in-lining) makes the programmer's understanding of the domain more explicit. I'm thinking of what you get when you look through a class (or at least interface) diagram (with suitable filters for the current level of detail), or a list of method names within a class, for nicely written OO code, in a good modern IDE (I'm used to IntelliJ but I think they all have good higher-level browsing features now).

If the programmer's understanding of the domain were perfect, then the functor-style expression of the domain would be the best kind of representation. But since the programmer's understanding is (highly variably!) imperfect, it's often super helpful to have some idea of what was going on in the programmer's head SEPARATELY from what the code, as compiled/interpreted, actually expresses. The degree of mismatch varies a metric crapton, of course. But I think that, for instance, frameworks do very well expressed in a functional paradigm, while enterprise code often prefers an OO approach, is partly the result of the relatively small programmer-domain mismatch in the case of frameworks and relatively large programmer-domain mismatch in the case of an enterprise system. (There's also the fact that many organizations tend toward hierarchy in a way that makes OO inheritance kind of make sense sometimes, even when from a pure programming perspective inheritance should automatically feel perverse; and the fact that large businesses like their programmers to be fungible, which any message-focused paradigm should play nicer with; but for the purpose of this comment I'm assuming only one programmer in a generically complex, poorly understood domain.)

Re. mechanics of pairing and cognitive effect: I've never used any formal 'pair programming' method, but in one coding job I did have a (senior) colleague often looking over my shoulder and mostly offering positive suggestions. In spite of our excellent relationship I still didn't feel like I could solve the 'big' problems with someone else present. This may be just a personality thing (I'm Myers-Briggs INTP, much more common among developers than in the general population; here's a recent survey of empirical work on personality tyes in software engineering), or maybe just the lack of a previously-defined method didn't leave me the headspace to tackle more complicated issues. But it did make my code better..although again maybe just because the other guy had a lot more experience. :)

OOC has anyone tried this pair programming method? (Didn't know anything about it until I interviewed two practitioners/inventors here.) I like the idea of investing in the relationship by forcing a shared and oral/aural understanding of the code, and it kind of does seem to formalize the sort of really valuable random coding chit-chat that can break you out of tunnel vision..but again haven't tried it myself.

Relevant feedback from an anonymous user (re. why it's better to trust Java EE):

Simplicity (It just works).

Love EE as it has these low barriers to entry that is typified by the kind of stuff the author talks about.

I dont want to "control" everything and happy to leverage the 100000man hours that have gone into making App Servers do all this stuff for me.

I want to solve business problems; not reinvent the wheel, so I use EE as, for me, there is no loner any reason not to use EE.

Nice! What do you think of those 'move your mouse around randomly' true-random input systems?

on the everything-is-an-object philosophy see this 2002 'Monad Manifesto' straight from Jeffrey Snover (PowerShell was originally called 'Monad')

We've got a Refcard on refactoring patterns here w/some book recs at bottom (including Martin Fowler's of course). The Kernighan and Plauger is BRILLIANT but not relevant to the OO stuff discussed in this thread.

Re. your 'polyglot suspicion' point: speaking only for myself, I do have application-wide mental models that are coupled tightly enough to the 'trunk' language (or maybe that's really just 'my favorite'?) to exert some pressure toward sticking with the trunk language (yes, probably memory-managed OO) 'wherever it isn't ridiculously unnatural'. The DDD 'bounded contexts' concept is supposed to help here but (for me anyway) it's hard to avoid leakage from the application-level (and somewhat language-bound) model. It's been tricky to reconcile the academic, Lispy+systems side of my brain with the productive, managedOO+platform side of my brain. I'd say that 'more experience would help' but while maybe more experience necessary it's certainly not sufficient -- maybe 'though more polyglot experience' would work. But then the existing 'children of Algol' (or at least C) codebases exert their own momentum and takes cross-pollination from telecom or embedded or whatever to expand the set of productive languages in a given application (or even enterprise).

Re. language<->domain optimization measurement point: exactly -- the interesting delta would be diff([optimal for some deductive reason like 'no shared state'],[actual for whatever contingent reason(=talent+f(expense,costTermDecisionmakersActuallyCareAbout)+fadpressure)]).

Interesting point re. contractors & I've noted that as something to dive into -- thanks. The 'nobody claims not to use agile' point is good as well; that's why, later in the survey, we asked about specific practices. But just the normal English word 'agile' may have meaninglessly muddied the conversation here, since the opposite of 'agile [the English word]' is unequivocally bad. I wonder whether the word 'extreme' in XP also didn't help, but for the opposite reason -- that managers responsible for profits and losses were afraid to do anything 'extreme [normal English sense]'.

The commodification of developers is encouraged by heavyweight frameworks too, I think (because the more constraints the framework places on developers, the more similar each developer's work is going to be..all other things being equal, of course, which they never are; but I think you can actually hire 'a Java EE developer' and be much more confident that you're hiring the right person than if you just hire 'a Java developer who built enterprise apps'). Wonder how heavyweight framework usage correlates with certain SDLC methodologies..maybe someone has noticed something..?

(Also thanks for pointing out the wrong link -- fixed!)

Full list we asked about (deliberately loose with 'methodologies'): waterfall, Scrum, Kanban, TDD, BDD, DDD, XP, DevOps, Pair programming. We received these as 'other' fill-ins (<10 for each): 2TUP, Ad Hoc, Agile, BizzDevOps, CI / CD, Code Reviews [we actually had a separate question about these], Code and fix, Feature driven development, GTD, iterative, Kaizen, Lean, MBSE, MDD, non-structured Agile, RAD, RUP, Programming mofo [haha], some concepts from PMBoK, rapid prototyping. Don't know if this responds to your 'pretty stacked' comment though..?

The thought-model/brain-expansion observation is nice -- thanks.

Would be really interesting to look at the model<->language mapping the other way round -- i.e., to know how languages distribute over problem space -- to put numbers behind intuitions based on historical yarns and deductive pictures derived from the language's preferred paradigm. For example, maybe I understand in principle why Lisp (or any logic-focused multi-paradigm language) is good for AI and that historically it has often been used for AI (maybe less modern narrow AI)), and that Erlang and Go are designed (for historical and CSP reasons) to handle concurrency elegantly and robustly. But how much of the AI problem space is actually covered by Lisp, the scientific/FP-heavy/array-dense space covered by Julia or Fortran, etc.?

I don't know how to measure this. LOC count, project count, PageRank-like library usage metric, languages used in papers by grouped topic and ranked by h-index all seem to fail (for different reasons).

We do have a bit of recent survey data on how developers feel about agile..prelim notes here, but we'll be publishing more soon. One interesting correlation that kinda confirms a few things people have been saying in this thread: for many methdologies and techniques, experience pushes 'highly positive' feelings to 'positive' (i.e. years of IT experience correlate negatively with estimated degree of method/technique utility). (Email me if you'd like to discuss further / suggest correlations to check -- we're not done analyzing our data yet.)

Perhaps :) btw how do these results square with your experience?

What are you talking about, of course the only way to start programming is Lisp via SICP, then Kleene on finite automata. ;)

..but seriously I wonder whether 'which problem you solve first' is more important than 'which language you learn first'. My first programming job was automating some MSAccess reports and I'm pretty sure this has left a strong relations+procedures stamp on my brain.

Ah! this one would be great to look into further..esp how stateful->stateless refactoring rate changes over time (as code rots) and by various static metrics (since as you say there's a lot of risk&uncertainty pressure NOT to refactor where many objects are stateful).

Fair point -- didn't want to steal the paper's thunder. But Tables 3 and 4 now added so you can skim reasons without downloading the pdf. :)

FWIW, I use the free Mingle tier (for a three-user, on-and-off side project) and it does everything I need. Pretty straightforward, nothing too fancy.

problem whenever tech is used by people who don't really understand it -- including method, including scientific method: http://calteches.library.caltech.edu/51/2/CargoCult.htm

Love it. But a thought on persuasion:

Amortize cost of speed decrease over projected application lifetime, discounted by uncertainty of application lifetime length and future runtime environment. Compare with cost of coupling tightness increase introduced by eager optimization, discounted by uncertainty of code inflexibility cost over time. Add extra weight to represent fraternal concern for future programmer trying to understand your code, on top of cash wasted on that programmer's struggling-through-your-hyper-optimized-code hours. SO many uncertainties about the future -- but at least right now I know I can make my code cleaner. People normally discount future utility with apparently ridiculous weighting on uncertainty, but often generational breaks ("what will this do to my grandchildren's world") override. Maybe the social argument -- the responsibility to future coding generations -- will sometimes be more persuasive than appeal to code cleanliness through itself? since it is fairly certain that other people will have trouble writing your eager-optimized code, while the relative cost of your brittle code versus your eagerly-performance-optimized code over time is much less certain.

Anyway I felt much worse when contacted by a poor puzzled programmer two years after I abandoned a codebase than when I wasted my own time trying to figure out what my undocumented epicycles were trying to do in the same blocks (of course it was a horrid optimization specific to the local network config).

Perfect, thanks!

Interesting..will multi-window support work with any apps? and/or is there a new API to let you handle behavior in a non-focus window more precisely? (Apologies if this was discussed in the keynote, which I missed!)

Couple of closing curlies were missing -- added them. @Peter, are we missing something else?

This makse sense to me..design patterns are accidental in Brooks' sense like pointed arches are accidental to stone ceilings -- of course they're one way to take advantage of stone's compressive strength (that's just a fact), but the selection of pointed-arch pattern should flow from the global design of the building. If you inject pointed arches just because they solve the 'ceiling' problem, and wooden lintels because they solve the 'need tensile strength' problem, then you may end up with something fragile and bizarre...

Email me (see my comment in reply to Shai's comment above) the url of the article you're waiting on and I'll check status.

Pending articles on profile are definitely on the way! :)

Nice!..merge/pull could work especially well for certain kinds of writing (for example, multi-author articles on best practices..some of which branch by paradigm, language, philosophy, constraints..). We're playing with diffing displays but man UI can be tricky. Great ideas, thanks -- anyone else want to chime in?

Markdown support is definitely on the roadmap. (We already support it in the commercial version of our platform.)

Got your email & will reply shortly.

Good questions, and sorry for the lack of feedback/transparency. Normally we aim for max two days from submission to feedback (rejection, editorial suggestions, or schedule to publish), but lately we've been missing that number pretty badly (combination of short staff and some new bugs in our moderation system). But we'll be expanding staff significantly over the next few weeks, so we should be able to provide feedback much more quickly very soon. Thanks your patience while we ramp up.

@Shai, I don't see any articles in moderation under your username (sa74997) -- do you happen to have the preview or edit url? Might be easier to email me (myFirstName+left(myLastName,1)@dzone.com) in case we need a little back-and-forth to locate your piece.

On transparency and feedback/improvement in general: what kind of info would you like to see, besides reads and likes on each article? We're actually gathering contributors' thoughts on an 'author analytics' page right now, so feel free email me about that too. Would love to hear more & can probably share screenshots of our current draft, if you're interested.

Wow, Semantic Scholar looks awesome! Thanks for posting. Can't believe I haven't run into it before.

On the general issue of public code hosting service fragmentation: getting these just right seems like a very subtle developer UX problem, clearly something GitHub hasn't solved. I know GitHub/GitLab/Bitbucket are all pretty great, but I wonder how effective the user feedback cycle becomes when a service hosts code from many mostly unconnected communities.

Variance in platform feature requirements doesn't have to come from technologies (languages, platforms, heavyweight frameworks) alone, but even (and probably more so?) from the way the particular community actually uses and shares code. But I don't know how the feedback cycle works for those platforms, esp. since their business models seem different. Is there a need to pool usage data and user feedback across source hosting platforms? I wonder if that's something we could facilitate.

The "explain changes that affect a community thoroughly and very openly" point is reminding me a little of when we relaunched dzone.com on our own platform last year..and we thought well of course everyone would be happy because the new site is so much prettier and faster and easier to use than the old one! and of course in the end it was a good move, I think. But we re-learned how much full communication with our developer community matters, and re-realized how easy it is for someone who provides a platform for a highly invested community to start feeling more like a generic service provider (like how you're describing Google Code) and less like a participant in the community (as Java has been for a long time).

Definitely want to keep this a serious tech discussion site! What seems like advertising in this piece? (True, it's about skills rather than code directly; but recently articles about career and skills development have been received by our readers quite well, and have often generated substantial discussion.)

Yeah I haven't seen the movies either but back in grad school everyone talked about the Saw movies (grad students disproporionately enjoy horror movies for not-too-hard-to-figure-out reasons) so I learned the name 'Jigsaw' and understand the basic premise at least (still haven't seen any -- no spoilers! maybe they're good). I like how the last panel acknowledges, engages, and comically deflates some recent (perhaps well-justified!) fears around the future of Java...

Still not invented: an awk that works on self-and-other's memories of all past conversations in relationship_history.log.

Haven't myself read Sam Newman's book, so I can't speak to its contents in particular. But while the general ideas behind microservices aren't new at all, as you note (you might say they're as old as Unix, but you could also trace the concepts waaaaay farther back in organizational management and military contexts), a few technical features taken together (single-process services, independently linked backing resources, web-based and often human-readable IPC) and system-definition and internal communication principles (the 'bounded contexts' of Domain-Driven Design in particular) are turning the commonsense notion of loose coupling into a really practical architectural style.

Before I read Eric Evans' DDD book and this post by James Lewis and Martin Fowler I also felt "no duh" about the whole microservices buzz. Maybe I should also read "Building Microservices", though. :)

:'(

Feeling guilty for every kill -9 from here until forever...

Yep, Sar had actually created a simpler version and then I asked him to make it harder -- so it's entirely my fault on that front. :) Juggling more values*abstraction-levels than the brain has registers can be so much fun, though..!

But this gets me thinking: what do y'all think of the following:

- In some cases, we can publish two versions of the same quiz -- one easier, one harder. (For example, @Sar, I know you already have an easier version of this quiz.) Then the reader can try the easier one first, and if they solve it without too much trouble, they can try the harder one.

- In the trickier cases, we'll include an explanation of the correct answer in the response to an incorrect submission..and come to think of it probably in response to a correct submission as well, in case your reasoning included a measure of hunch.

How does that sound?

Hmm can you clarify? I don't understand what you're getting at, but I would like to. :)

Glad this is now clear! -- thanks @Adam and @Sar. :) Would "Java Puzzler" or "Java Brain Teaser" be less confusing? @Ben, your thoughts on the series title are also welcome, of course.

@Martin and @Hung, have you run across any useful patterns, rules of thumb, design principles, best practices, etc. for microservices?

To understand the kind of concretes you're talking about (how to define boundaries, manage interaction..the stuff you still have to figure out after you get the idea) I usually take an onion-skin approach: look first at deeper/broader concepts (say, Eric Evans' DDD, or the book Sam recommends), then at design patterns (to capture something of real development experience), and third at complex, real-world examples (to see an actually working system in detail), preferably with lots of readable code annotated to explain design intent. Architectural diagrams from multiple perspectives help me a lot, too -- not just a physical or logical architecture, or class diagram, or control or dataflow diagram, but all of the above.

These books are some of my favorites for the 'from paradigm to examples' shift. Many articles include material at all of these levels.

Brilliant site. Well-tagged, too.

Sure, that's what Sam pointed out in the article -- probably lazy won't help, but of course if it does (e.g. frequently opened db connection) then adjust accordingly.

As I understand James' image in relation to the article: the article proposes a rule of thumb that instantiates the general point Knuth is making -- and ∀-rules and thumb-rules both introduce constraints that reduce decision space and thereby stress etc.. 'Less thought required' isn't as good as 'without any extra thought required', but it's getting there...

So to flesh out the thumb: what are some other 'exceptional cases in which lazy initialization really does make sense'?

Ha, good idea, thanks! Mild embarassment in one's own eyes can indeed be a great motivator to better code...

Ha. Would say "no duh" except that I can't count the times I've smacked myself in the head for leaving database connections open.

There should be a "Checklist for Bad Things You Knew About Ten Years Ago But Still Do Anyway".

This is a great point that Stefan's article addresses but hasn't come up much in the comments so far. Agile is all about delivering value to the customer, maintaining a sustainable development pipeline, building honest relationships among engineers, business people, customers, etc. But how does the development of individual developers' skills fit into this?

Pretty deeply, I think -- at least if the project goes well. For example, in maybe my most successful coding project, my manager was my (older) brother, who wasn't a developer but was technical enough to translate requirements and implementations both 'down' to/from me and 'up' to/from the users (all internal). He and I already had a great relationship and knew how to communicate with each other quite well, so personality mismatch wasn't an issue. Before that project I was still in a 'dump more and more procedures into a few fat classes and call it object-oriented, and slap some boxes and buttons on top of some tables and call it a UI' mode and figured that he'd only help me make my forms look pretty -- but in fact I ended up redesigning more than half of the application just because I always had a high-bandwith line to the end-users. This one project made me grow a lot as a developer (or at least I think it did!) -- not at a procedural level, but at the level of domain modeling and object-oriented design.

Can poorly-managed projects harm an engineer's growth, though? say, by encouraging him/her to grow suspicious of a method or philosophy because people messing things up are using the name of the method or philosophy as 'silencing' weapon or a band-aid (possibly with high opportunity cost), no matter what decisions they are actually making?

Agreed. One annoying little word-magic issue is that you can't sound reasonable in a meeting if you object when someone says "We need to be more agile!" because of course "clumsy" or "unresponsive" aren't good..and over an oral/aural channel you can't tell whether "agile" has a capital 'A' and refers to the Agile Manifesto, the ideas and practices behind that text, or just a vague idea that "visibility is good" -- which can easily blur into "never trust an engineer".

DDD tries to address the doublespeak danger (good word-choice @Joel) at a substantive level, I think, without targeting any management philosophy in particular.

Possibly interesting points, but can't tell if some wires are crossing here: why do you say "WRONG" to each of these claims?

My impression is that the article actually agrees with what you're getting at (if I understand you and the article correctly), but focalizes heavily in order to reflect the feelings that many developers that Stefan has worked with have actually expressed.

I've seen many of these complaints expressed before and have felt all of them myself. Too often, I think, when "Agile" is invoked, the real, inescapable engineering requirements (technical and organizational) are not sufficiently addressed. The word "Agile" becomes a cloak for not bothering to think with clear engineering sense -- that's the idea captured by the "cargo cult" phrase.

@Stefan, do I understand your points correctly, and @Marcelo is this also what you're talking about?

That's a good point re. mixing tools -- I could say that "in fact people do sometimes choose between JIRA and GitHub for issue tracking because GitHub Issues isn't too shabby so if you're using GitHub maybe you should just stick with the built-in feature and not worry about another tool?" but that lumps things together in a general conversation (the article) that only happen to be lumped together in a particular situation (my choice point).(On the other hand, my Unix side wonders whether the size of many tools' feature-sets and the resulting feature overlaps among tools -- the things that make these heterogeneous option sets available in the first place -- aren't just mistakes inherited from factory-centric organizational design principles.)

Thanks for the feedback. Title changed.

That's true (also @Csaba), but you might have to choose between option (a) which includes TFS and not Git (even though TFS does support Git -- say for solution-integration reasons, like "we're going to use TFS only with TFVC") and option (b) which includes Git and whatever other ALM stuff. So I think the title seems a little apples-to-oranges but sometimes in actual moments of choice -- because in-prod technology selections are not atomic -- you do have to choose between apples, on the one hand, and oranges, on the other.

A bit orthogonally: if Paul Lockhart is right, then math will be very hard to teach non-pathologically for at least the current, and probably also current+1, generation of teachers. Lockhart's argument really jives with my experience -- I had to unlearn years of robot-brain nonsense in order to do any linear algebra without hating the universe. (This book helped in all sorts of ways, although I wasn't mentally ready for it until Better Explained had already convinced me that a big part of the problem was the pedagogy.)

A bit less orthogonally: totally agree that coding doesn't have to be learned in college, that undergrad CS degrees teach a lot that rarely comes up in many (managed-memory) developers' coding lives, that university education is often a huge waste of money.

One issue, though: when you do need to start thinking about deeper stuff like linear programming, Bloom filters, state machines, Lamport clocks, etc., where do you learn that? I don't know any good centralizing resource (so, Google?) -- MIT OCW, if I had to pick one, but that too is so far from user-friendly.

public class lol extends laugh

Yes! :)

Oh very interesting..thanks for the book note. Do you recommend it?

100% understand re. programming in types. Have been stabbing at this book on and off, and feel like I have occasional epiphanies while reading various bits, but nothing concrete enough to apply in code.

Traits are interesting too (and more intuitive for me), and someday I'd like to see what it's like to program in Rust..on whose type system I found this post helpful...

The NPE and syntax features are really nice though. :) But yeah afaik the biggest diffs between Kotlin and Groovy are Android (possible in Groovy but slow) and IDE (supposedly Kotlin is lovely in IntelliJ, as you might expect, though I haven't tried it myself) support.

The study I linked re. why devs choose a language (not the feature-set) is probably a bit skewed by professional convenience, rather than for fun/curiosity, so if you're wondering about just playing with Kotlin for now then maybe think of it as 'easier Scala' or 'faster Groovy'..but I haven't built anything serious in it so can't verify that independently.

We can also ask the project lead about diffs vs. Groovy..got an interview lined up..!

learnyouahaskell is on my reading list, if that's what you're getting at. :)

..and honestly I generally do feel more functional than OO. (Keeping the 'Lisp is beauty incarnate' tag in my bio permanently -- or maybe until I learn me a Haskell!) The knock on lambdas was a bit of a joke, lightly mocking (say) Smalltalk zealots who actually hate anything that isn't deeply messaging-focused.

Yep, we're open to this kind of thing -- to start, please fill out this Refcard proposal form. Reply here if that doesn't work..just switched this out from Google Forms and a few users have had a little trouble (that mysteriously went away on its own). Thanks.

For something a little different, what do you think of SICP or Bryant and O'Hallaron? SICP helped me bridge abstract compsci coursework with actually writing code, and Bryan and O'Hallaron (which I admit I haven't read fully) helped me decide how much to trust compiler guesses and runtime abstraction (for me this meant .NET).

I've only read about half of your list and now have loads of great-looking reading material -- thanks for this post. :)

True. Sometimes release plans clearly indicate what will not be backwards-compatible. For 'known factors on the horizon', would an in-line code tag/taxonomy help? in case the release plan doesn't specify what will change at a level concrete enough to search for substrings (class names, methods, keywords) in the codebase. Thinking something like ReSharper, but for the future. If such a taxonomy were standardized, then changelogs could also be released in this format, semi-automating any refactoring you might have to do to keep your code up-to-date.

For 'computing past trends', I don't know how to do these in a domain-independent way (like a VAR model or somesuch). How would you construct a predictive model based on singular, engineering-specific cause-effect pairs like 'the effect of the the rise of inexpensive multiprocessing on parallel algorithm selection'? Maybe there's a way within a given platform space ('how fast do JSRs move' or 'how frequently do JS MVC frameworks require shims for backward compatibility')?

Problem space modeling failure and domain change can both be measured, I guess. But the latter seems especially hard. How frequently do requirements change after the initial release, and how deep in the code/architecture do those changes cut (measured by function points..again expensive)? Projected domain change rates would have to come from domain experts, translated into code-impacting ways via some method like DDD context maps or Gherkin. That would be neat, though.

Interesting..could you attach {rate of staleness increase by time unit, final stale-by date, {set of independent variables with relation to the first two} to individual features, feature sets, packages, or actual code blocks? so like (to pick a simple version) "this component will be stale as soon as the next version of MySQL is released because we know the new API won't be 5.6 compatible" (but as a machine-readable, hierarchical tuple).

Good points -- both could be added as weights in a slightly (but not massively) more complex model -- are you aware of any research in this direction? I know the literature is vast and my quick Google Scholar search doesn't yield any easy answers.

Re. 2c though: is there an inverse relation between non-deliberate technical debt accrual and accuracy of feature point record? But the opposite for deliberate technical debt accrual (since presumably you have some idea how much you're accruing if you do so deliberately).

In a perfect model, function point analysis would also be necessary, I think (otherwise the systemic impact is invisible). But also very expensive.

Nice, thanks -- and wow, what a cool wiki page!

VMWare's deep-dive into how they virtualized x86 is also a beautiful read.

Should be fixed! :) Does it appear in your article list now?

Nice, thanks. Harlan Mills is a high standard to live up to. :)

Neat! -- can you post a link to these studies? Would be interested to read further (esp. to understand what the authors mean by 'productvity').

Ahh, good question -- thanks! We're basically interested in two things: (1) does this help readers make better software? and (2) does this drive readers away? The trick is that hard-to-pin-down things like 'tone' and 'angle' can make (1) and (2) both true -- so if your post sounds like it's promoting a commercial product/service, then even if it's really just celebrating the open-source project that the commercial service supports, it might still rub readers the wrong way.

Does that help at all? Of course it's hard to tell tone 'from the inside' -- genuine enthusiasm to one person is prosetylization to the next! -- for now am just trying to give a sense of moderators' reasoning. Will try to find some examples (of 'this is fine' and 'this probably kind of crosses the line tone-wise') and include in the general guidelines post.

Section titles formatted as headings, paragraphs broken correctly, text flowing around images (or images breaking text) so that lines of text are longer than one or two words, code blocks formatted with readable line breaks and indentation (and commented if necessary), no meaningless whitespace. Does that answer your question? Maybe this should go in the article, too. :)

Not specifically about documentation, but related point re. high-level languages: http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

Makes sense, and I understand that religions about technology are always wrong (and lazy and harmful). But I just wonder why, psychologically, clean abstraction in particular keeps riding the zealotry bandwagon (this seems to be true in the JS world too..looking at you, Angular). True, immutability alleviates side-effect worries; but pure function machines will be incredibly inefficient or unpredictable (how can you allocate finite memory for absolute black boxes? although I think Rust's lifetimes try to address this) until context switching is costless and garbage collection instantaneous, which both seem impossible (thread pools and generation-interleaved garbage collection are good tries, I guess).

Psychologically, at least to me, it feels like desire to latch on to the One True Clean Abstraction is an attempt to ameliorate the incredibly frustrating juggle of humility (because you are certainly missing things you could not-miss), defensiveness (because you can't anticipate everything even if you miss nothing you could have thought of), and perfectionism (because, really, things unrelated ought not be related).

"A lot of performance issues come from impedance mismatches between programming model and what happens under the hood."

Right -- abstractions are never quite perfectly clean; the Shannon ideal doesn't distinguish code/decode from run. But mismatches go both ways..machine language doesn't map any problem domain very well. I guess downward (metal-directed) mismatch causes more trouble at runtime, while the upward mismatch (domain-directed) causes more trouble at maintenance time.

Microservices (at least as 'socially' implemented by 'feature teams') serve the upward nicely. But I wonder if this presents an extra danger. The upward is more visible from the outside than the downward impedance mismatch, so there's more management pressure to conform up rather than down. And powerful platforms (Java and .NET quite a bit; JS/browser probably a lot more) make it relatively easy to write code that gives you a working feature set despite massive inefficiencies arising from failure to attend to where how much data is going over which channels given which inputs etc..

OOC what about current microservices talk reminds you particularly of the EJB buzz, besides general overapplication of a hot tech for no good technical reason? is it also specifically the (not fully rational) attractiveness that derives from (self-flagellating? or at least emotionally self-serving) search for clean abstraction?

Shouldn't the social and technical be at least decoupleable, though? DDD helps design primarily and implementation only secondarily; in a way, the Conwayish comms structure is just a View. But yeah to me the main value of the microservice heatwave is that it pushes you to think DDD.

Socket-channeled microservices are no more panacea than Smalltalky message-passing, of course, but I think any talk about loose coupling is always going to sound appealing because when you run into pain thanks to tight coupling you don't just have extra work -- you also feel how stupid the earlier decisions were, and you get mad at whoever wrote this hideous spaghetti code. And then -- and here I'm speaking from inexperience, I guess, never having written anything as deep as a data grid -- you remember how many times, as you wrote your code, you felt sorely tempted to diverge from the clean separations presupposed by your architectural diagram, and you just want to drill the loose coupling message into your brain by keeping I/O as tightly gated as possible..so in your desire for self-manipulative self-improvement you jump on the loose-coupling-of-the-month/year bandwagon. (Though in my case I feel like this self-manipulating pressure will disappear with sufficient experience.)

Makes a lot of sense. Totally agree that debt without repayment plan is more like sucking life out of the future, not betting on the future.

But the distinction can be hard to apply, I think. For any non-trivial application, you always might be able to make the code more maintainable. Often you just aren't sure how the work-to-benefit ratio will pan out over n months, esp. if requirements are in flux. In the pure case this is just the Entscheidungsproblem, but workaday it happens constantly.

So how do you decide what's a mess and what's just..a bit rushed? :)

Thanks, Dave and Shai. I've heard a growing number of opinions like this lately, especially from folks that not only have used Java but also have been passionately involved in the community for years..but also, on the other hand, a good deal of enthusiasm around Java 8 and occasionally even neato-and-apparently-somewhat-developer-driven stuff (FastR, Graal, PGX) at Oracle Labs. But I can't speak to this from my own experience.

On another note, any thoughts on how the JCP is doing now -- esp. re. innovativeness and openness -- vs. Sun or immediately post-Sun Oracle days?

Ha, thanks for catching those typos -- should be good now.

And Tom did gather a lot more about these players' roles during those interviews..stay tuned. :)

Okay, I won't ask you about the DOM..for now. :)

Good thought -- but is the hangup JS itself or just the DOM? For me JS syntax is fine -- it's just unpleasant to jam a marked-up-document peg into an object-oriented, somewhat-Java-inspired hole.

Right -- so your claim as I see it is basically: getRateOfChange(Java, magnitude of change) < getRateOfChange(Swift, magnitude/change), where magnitude of change = f(depth*utility of language fundamentality per change). Correct me if I'm oversimplifying or misunderstanding. And you're not saying that Java isn't getting better, or that Oracle isn't doing a lot of work on Java 9, just that it's not growing as..swiftly..as Swift.

So I wonder whether we might expect the rate of fundamental change of a language to be inversely proportional to the size of the platform (say, classes*methods), and the size of the platform to be influenced, at least, by some function of both age and current size of userbase? In which case it just makes sense, no knock on the superplatform, that newer languages would reinvent themselves more deeply faster, like weekly-identity-swapping teenagers versus set-in-their-ways adults. That sounds better to me than 'mass and inertia' -- which of course could still be slowing things down on top of (and independently of) maturity-caused molasses.

More concretely: the number of times I've thought "Man, wouldn't it be great if this were already implemented somewhere!" is way larger than the number of times I've thought "If only this language were more like Lisp!" (no matter how much I'm in love with Lisp) precisely because Java (or, say, .NET) can already do so much stuff for me. So if I were to contribute to some JSR (which I haven't) then I'm much more likely to add features higher up than dig down and, say, add native support for a different programming paradigm. If I really want to do something a language can't do, I'll just switch languages, nbd.

I'm curious -- do you have an opinion on innovativeness in / deadness of .NET vs. Java? or for that matter W3C APIs?

Interesting piece, Rob -- thanks. For us still-Java-lovers, though: can you suggest ways to give Java a back-to-life jolt? I get what you're saying about newer ecosystems seeming more vibrant and adjusting faster to real-world needs, but to me one of the most exciting things about Java has always been the JCP -- the whole point of which is to do exactly that. Do you think that process needs to change somehow? (Do we need to revive Apache Harmony..?)

Mike, thanks for this sensible article.

Re. frameworks, question: how do you factor in the uncertainty of the product plan? For example, you know with 80% certainty that you'll be adding feature X that framework F makes really easy in M months, but right now using framework G will save H hours over using framework F. Do you say 'break-even is M+N months' and just put it in a spreadsheet? or just: how do you weight future potential of a framework that you're choosing now?

This quote from Oracle seems particularly odd: "Given the widespread dominance Android has achieved with its continued unauthorized use of the 37 Java API packages over the past few years, Android has now irreversibly destroyed Java's fundamental value proposition as a potential mobile device operating system." (emphasis added)

Presumably 'Java' (something way more people than Oracle care about) here refers specifically to 'Java ME' (something that mostly Oracle cares about as a mobile OS). Android developers are still writing Java for a mobile OS, albeit platformized on Android rather than Java ME. The Java/Java ME slip (though legally correct, I assume) suggests a perspective far from the Java developer's.

Indeed! cf. the recent IEEE list -- interesting how different results compiled using a different method (from a bigger, more varied, and differently skewed data set) can be

Ross, thanks for sharing your current stack. The Java/threadpooling headspace is so different from async/non-blocking that I'm having trouble .

How is Angular 2 treating you? We've used Angular and it's really nice for highly mutable SPAs, but I'm not 100% sold on SPAs themselves..seems contrary to some vague idealistic ethos of the web...

Yeah, 25% of bugs are apparently in the requirements themselves, and another 25% are structural..according to some huge study I can't remember but can probably find if anyone is interested.

How important is the abstract compsci stuff, though? -- the part that kind of is a little magical, that makes it possible for putting-things-in-little-boxes-and-shifting-them-around to generate valid inferences, traverse graphs, calculate values of functions with arbitrary limits, pixelize projective geometry, do a massive linear regression in milliseconds?

Ha! Great article. Sort of the converse of Fred Brook's No Silver Bullet piece. Sadly I haven't done enough assembly to feel the magic of the JVM go away. But I see what Uncle Bob is getting at, and far too often I do hit 'wait a minute, that was incredibly simple..dammit' moments..that aren't revelations but just annoyances at my earlier (and damaging) magic-feeling.

Ultimately this kind of info would be more useful in a structured catalogue, but rubygems.org doesn't provide use-case recommendations. Are there any structured directories of gems that let you, for example, list all ORM gems?

Hey, thanks -- that BLOBbing really sucks and this looks pretty easy.

Good thought -- and we're even publishing a forty-page 'Guide to Software Quality' in a few weeks. :) Would love to hear what you think of that longer treatment.

I guess unit tests seem like a great manager's-eye target because they are relatively easy (a) to create, (b) to measure, and (c) to interpret ('code coverage' is such a simple metric). Of course where e.g. integrations are likely to be sticking points, unit tests will be less likely to catch real errors..how much energy to put into which aspects of software quality will always be a business (resource-based) decision, grounded in but not completely determined by the software architecture.

I see how this might save resources, but won't this potentially make program behavior unpredictable (and also potentially degrade user experience)?

This seems extremely basic..maybe easier just to link to Oracle's Java Tutorials?

There are some pretty funny jokes in there, but the rest of the Twitter conversation seems to confirm.

Wow, this is quite a list. :) I've encountered many of these claims anecdotally but am wondering about response bias (how many developers would post praise of their good managers?) and I bet someone has done empirical work on this. Anyone have any supporting data, esp. for claims 1,2,4?

Wow @Akmal that's an awesome slide deck thanks!!

On a related (get it haha) note: we've started to build an rdf/owl ontology of data stores (among other things)..would you be interested in lending us your expertise to make sure everything is correct?

Sounds like a good counterexample.

In general I see more good writing on exception handling antipatterns than positive exception handling patterns. Anyone want to suggest any resources on exception handling patterns, both language-neutral and language-specific? Best I know right now is the c2 wiki page.

Yes, 100%. Give me an ugly static HTML page and (these days anyway) decent odds are there's something worth reading on it. And my mobile phone&plan won't creak. On the other hand, as you say, we publishers need to make money somehow. :) But of course we only want publish people who already have something to say. But this can easily make the content<->ad match incidental and/or weak..so the basic cruft problem is unsolved even at a non-technical level.

Interesting! Have C++ and/or C# changed strings over time to such a significant degree?

and deeper still

deeeper in the thread

reply to a comment here

nothing is this hey this isn't a reply or is it??

what is a comment here it is

Wow, how did I not know about the Ultimate Hacking Keyboard..looks amazing! & thanks for the mention. Combine with keylogger, correlate with particular languages/frameworks, and offer downloadable 'keyboard for language L' layers.

Also wonder if different typing habits influence coding decisions at all. Ny fingers definitely remember lots of platform boilerplate, but are these muscle-memory patterns completely compartmentalized from muscle-memory generated by non-coding typing?

Wow, how did I not know about the Ultimate Hacking Keyboard..looks amazing! & thanks for the mention. Combine with keylogger, correlate with particular languages/frameworks, and offer downloadable 'keyboard for language L' layers.

Also wonder if different typing habits influence coding decisions at all. Ny fingers definitely remember lots of platform boilerplate, but are these muscle-memory patterns completely compartmentalized from muscle-memory generated by non-coding typing?

'Specific applications' is a good distinction -- do you use different layouts for different applications?

This question is interesting to me partly because I ran into this article on gesture keyboards, and it seems that one of the neat things about non-physical keyboards is that the layouts are very easily adjustable on the fly...

'Specific applications' is a good distinction -- do you use different layouts for different applications?

This question is interesting to me partly because I ran into this article on gesture keyboards, and it seems that one of the neat things about non-physical keyboards is that the layouts are very easily adjustable on the fly...

Impressive, thoughtful article -- thanks for the post.

As a matter of empirical fact, I guess, any code change de facto increases the chance of random bug popup. There's been some empirical work on the correlation of refactorings with bug reports, and overall it looks like refactorings and bug reports correlate positively. But maybe most of those generic refactorings were stupid or at least 'not best'. Figuring out which refactorings are 'best' is exactly what will help us get past the generic and into the actionable.

More granular empirical work on the cost/benefit of refactoring seems to have ballooned a bit over the past two years. I've only skimmed a few of these, but you might find some of these articles interesting.

Impressive, thoughtful article -- thanks for the post.

As a matter of empirical fact, I guess, any code change de facto increases the chance of random bug popup. There's been some empirical work on the correlation of refactorings with bug reports, and overall it looks like refactorings and bug reports correlate positively. But maybe most of those generic refactorings were stupid or at least 'not best'. Figuring out which refactorings are 'best' is exactly what will help us get past the generic and into the actionable.

More granular empirical work on the cost/benefit of refactoring seems to have ballooned a bit over the past two years. I've only skimmed a few of these, but you might find some of these articles interesting.

Good questions.

1. [driver of agility] It seems to me that the developer of project P can anticipate P's possible future pivots better than anyone else -- just because P's developers can know what P can do (but doesn't) almost as well as what what P can do (and does). So if write a class C that doesn't have exactly have methods for doing x but does grab as much space (name, memory, cycles, whatever) or implements a similar control structure as doing x would need, then I might have a decent idea of whether or not I can just fiddle with C to do x (without screwing up the rest of the application). But here I'm jumping from massively abstract ('affordances are pragmatic') to anecdotal (it just so happens that I sometimes feel what my code isn't doing but could).
   
   But I guess my thought is that codebase c can be 'more agile' (=able to change direction quickly) than codebase c' even if both c and c' have the same heavyweight plans with the same degree of investment -- and that it's precisely the engineers (especially architects, presumably) who can make c as opposed to c'. (We'll need to distinguish 'good coding practices' that focus on maintainability and updateability from coding practices that produce agility measured in this rate-of-change (as opposed to rate-of-repair or rate-of-improvement-along-similar-lines way.)
   
   
2. [what to invest in] This is a good question and I don't have a solution that doesn't pit engineers against product managers! I guess it's important that all involved parties should invest heavily in the envisioned use cases. But that has very little to do with engineering as such, which means we're relying on engineers to be 'just people' too -- which is fine, but not something the team can control.

Good questions.

1. [driver of agility] It seems to me that the developer of project P can anticipate P's possible future pivots better than anyone else -- just because P's developers can know what P can do (but doesn't) almost as well as what what P can do (and does). So if write a class C that doesn't have exactly have methods for doing x but does grab as much space (name, memory, cycles, whatever) or implements a similar control structure as doing x would need, then I might have a decent idea of whether or not I can just fiddle with C to do x (without screwing up the rest of the application). But here I'm jumping from massively abstract ('affordances are pragmatic') to anecdotal (it just so happens that I sometimes feel what my code isn't doing but could).
   
   But I guess my thought is that codebase c can be 'more agile' (=able to change direction quickly) than codebase c' even if both c and c' have the same heavyweight plans with the same degree of investment -- and that it's precisely the engineers (especially architects, presumably) who can make c as opposed to c'. (We'll need to distinguish 'good coding practices' that focus on maintainability and updateability from coding practices that produce agility measured in this rate-of-change (as opposed to rate-of-repair or rate-of-improvement-along-similar-lines way.)
   
   
2. [what to invest in] This is a good question and I don't have a solution that doesn't pit engineers against product managers! I guess it's important that all involved parties should invest heavily in the envisioned use cases. But that has very little to do with engineering as such, which means we're relying on engineers to be 'just people' too -- which is fine, but not something the team can control.

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

@Jaime, good point re. boilerplate vs. patterns. I think we also sometimes apply the concept of a pattern too broadly even when we don't just insert some boilerplate implementation. For example, you might still use produce too many objects using a pointless Factory even if you don't implement a Factory with boilerplate code.

@Matthias, I don't know the solution to the problem you observe. I've 'thought ahead too far' way too often, resulting in bloated and (surprisingly often) brittle code. In most cases this has probably been smart-aleckiness -- going beyond behavioral specs, thinking how the users might (but have no real plans to) use the software. Is it enough to just say 'stick to requirements' and that's it? I'm tempted to say no, because the developer often knows better than anyone else what the program is capable of. Then the choice is just between strategic management (requirements) vs. entrepreneurial (what this could possibly do) decision-making. And sometimes, especially when it comes to technology, entrepreneurial thinking really does work better.

But to the practical issue -- how do you decide whether a given piece of code is going to be reused often?

@Raging makes another good point -- I don't really have a taxonomy of pattern misuse in mind. But I'd like to build one. :) At least, I feel like it would sometimes help me avoid bloat, and maybe others too. Maybe we could even build a nicely articulated ontology, or a richer (more structured) pattern language...

@Serguei has also touched on another interesting idea. Certainly it's wrong to think of patterns as the 'correct' way. That's just student & CYA thinking -- just trying not to look like you've done something the wrong way. It has no place in any kind of craftsmanship, or business for that matter. But perhaps patterns' educational role suggests a third benefit, in addition to modularity and DRY. Because patterns structure code in commonly-accepted ways, use of patterns can help others understand your work. More articulated, 'thin' patterns might do this even more effectively -- say, especially if we develop naming conventions that clearly communicate their place in the hierarchy (as specializations of broader design patterns). Or maybe I'm on the wrong track..?

Nothing wrong with the mechanics, of course, but still a little funny because (my silly) stereotype affirms that CoffeeScript lovers love CoffeeScript so much that they never want to see anything but CoffeeScript. Even when actually writing a compiler. :)

Juxtaposing CoffeeScript and C also tickles a sort of funny-bone, because in terms of relative distance-from-the-metal, CoffeeScript and C are opposed, of course, but in terms of relation to a lower-level predecessor language, you might humorously see CoffeeScript->JavaScript as (very roughly) C->assembly (if you're already thinking like dmr).

Nothing wrong with the mechanics, of course, but still a little funny because (my silly) stereotype affirms that CoffeeScript lovers love CoffeeScript so much that they never want to see anything but CoffeeScript. Even when actually writing a compiler. :)

Juxtaposing CoffeeScript and C also tickles a sort of funny-bone, because in terms of relative distance-from-the-metal, CoffeeScript and C are opposed, of course, but in terms of relation to a lower-level predecessor language, you might humorously see CoffeeScript->JavaScript as (very roughly) C->assembly (if you're already thinking like dmr).

Scale is not an abstraction in the architectural sense, true, so perhaps OP's choice of words was unfortunate. But what he was going for, I think, is a necessary and sufficient condition of 'cloudiness', which might serve as the most useful single index of 'cloud computing'.

It does seem to me that such an index would be helpful, if only as an easy way to cut through the cloudwashing. Is 'scale' useful for this purpose?

Less rhetorically, and more technically: whatever this index turns out to be, it would be very useful to map this index onto full-fledged architectural features. That way the form of the architecture itself will designate X 'cloud' or 'not-cloud'.

My best guess (and I'm not an expert by any stretch) is: anywhere a complex distributed consistency model informs an architecture, that architecture is concerned with scale, and should be considered 'cloudy'. (My thoughts come in great part from this paper.)

But you would be able to construct the architecture->index map much better than I would. (Or maybe someone has done this already, and I just haven't seen it.) Any thoughts?

Scale is not an abstraction in the architectural sense, true, so perhaps OP's choice of words was unfortunate. But what he was going for, I think, is a necessary and sufficient condition of 'cloudiness', which might serve as the most useful single index of 'cloud computing'.

It does seem to me that such an index would be helpful, if only as an easy way to cut through the cloudwashing. Is 'scale' useful for this purpose?

Less rhetorically, and more technically: whatever this index turns out to be, it would be very useful to map this index onto full-fledged architectural features. That way the form of the architecture itself will designate X 'cloud' or 'not-cloud'.

My best guess (and I'm not an expert by any stretch) is: anywhere a complex distributed consistency model informs an architecture, that architecture is concerned with scale, and should be considered 'cloudy'. (My thoughts come in great part from this paper.)

But you would be able to construct the architecture->index map much better than I would. (Or maybe someone has done this already, and I just haven't seen it.) Any thoughts?

Hi Ajya, thanks for the comment! I agree with you -- though my impression is that plenty of developers learned C# first because .NET offers so much leverage.

But this raises an interesting question: do different developers just have different learning styles? that is, do some like starting hard and going easy, and others like easing in before tackling a less hand-holding language like C++? Like Codeacademy vs. Programming from the Ground Up...

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Sweet game! I'm a sucker for laser glows. Didn't see anyone else in there when I tried it -- but, does the endless galaxy make it harder for individual users to find one another (esp. without landmarks because you're in space)?

What you're saying about the problems with HTML5 game development sound spot-on -- a lot like what EA and Zynga people were saying at the HTML5 game conference a couple of months ago.

Given HTML5's messiness, what made you want to learn it and build a game in HTML5 (besides awesome curiosity)? is it just the interoperability promise?

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

Creating a table with a facebook_id field and an email_address field sounds like it would give you the lookup you need..but maybe I'm not understanding your question. Are you currently using user email addresses to identify users, once they go through the checkout process (since you said that users don't actually login..I'm guessing you ask for email during checkout)?

The Wikipedia page on OpenID is pretty good, I think.

You can get the latest IE10 developer preview here, although you'll also need the Windows 8 Developer Preview for that.

MSFT's full IE10 guide for developers is here.

For specific feature support, Try caniuse.com's IE9 vs. IE10 comparison here -- then play with what features and browsers you want to compare.

For a more discursive analysis: Sencha wrote a nice Win8/IE10 first look article here (emphasis on HTML5).

You can get the latest IE10 developer preview here, although you'll also need the Windows 8 Developer Preview for that.

MSFT's full IE10 guide for developers is here.

For specific feature support, Try caniuse.com's IE9 vs. IE10 comparison here -- then play with what features and browsers you want to compare.

For a more discursive analysis: Sencha wrote a nice Win8/IE10 first look article here (emphasis on HTML5).

That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).

All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)

That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).

All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)

That makes sense -- you should be able to use any framework you choose, and then actually choose the framework suited to the project (say, to meet the client's requirements). So maybe rating a framework isn't as useful as comparing and contrasting it with other frameworks (like Socialmention tries to do).

All else being equal, though, don't some frameworks fit individual developers' coding styles better than others? (Not everyone likes ORM, for instance.)

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).

Interesting. Why do you think large corps and gov depts account for most of the remaining IE6 installs?

I'm not doubting, just wondering how we would know (or conjecture).