Top-Down on Top Again

It's a little old-fashioned, but I remember when we used to think of procedural languages as "top-down", & object-oriented languages as "bottom up". In the former, you looked at the verbs - what needs to be done - & then you broke these down into smaller units of work, etc. In the latter, you looked at the nouns - the things in the system - & modelled these to provide the basic operations that were built up to create bigger relationships.

It's a long time since I taught this ... stuff ... so I do hope we've progressed. I'm not convinced that everyone's aware of the progress, though.

I'm a keen BDD follower - every product I build follows the general principles of answering

• What does this product promise to do? 
• (what is its behaviour?)
• How is it going to be used? by whom? 
• (what is the context?)
• How does the company make maximum benefit from (justify) any given feature? 
• (what is the value proposition?)

These are very top-down questions. I don't care about the technology or even the problem that it tries to solve. The architecture of the solution, its maintainability, etc, are not a priority; that's for engineering's expertise. Performance probably is interesting - or at least the importance of performance needs to be determined.

From a project management point of view, I have other questions -

• How do I know when it's ready (enough)?
• How do I prove that it's ready enough?

This is strictly BA/QA work. No devs need be harmed in the making of these decisions.

If you look at that approach, you might think that I am a non-technical manager (product or project). I'm not. I'm a top-down developer at heart.

I believe that, even if a developer is not involved in higher levels of abstraction directly, they need to be exposed to the helicopter view, be able to provide feedback on it, & always keep it in mind with their deliverables. Without an understanding of how a release (candidate) moves the product closer to its user base or marekting's promises, there is the increasing chance of disconnect between the product that is being developed & the expectations that are being set outside of engineering.

The days of "I can prove that this software solves the problem you gave me through statistical modelling of outputs correlating to the results provided by business analysis" are in the past.

The days of "You said you wanted a user to be able to check their status anywhere" are here.

Return to Spotswood

There was once a great Australian movie called "Spotswood", about an efficiency expert sent to a small company producing automotive parts with the intention of improving efficiency & potentially laying off workers. When the expert gets to know the workers, & how their inefficient ways create a culture of camaraderie & new skills that could be of benefit to the survival of a more diversified business, he regrets the recommendations he had made on financial & professional assessments alone.

Watch the movie. Anthony Hopkins is brilliant. Russell Crowe doesn't spoil it. Toni Collette is sane.

The point I will get around to eventually is that you can't assess a team's efficiency by looking at its output alone, or its contribution to revenue. You have to also look at its potential for benefiting the company in other ways - such as their ideas & innovation potential, a feeling of well-being or loyalty that keeps staff turn-over low, or simply the store of knowledge that they represent across the business & the industry as a whole.
The object of the game is for management to recognise & harness that potential.

Over many years in the IT industry, I have seen a slow shift from a somewhat haphazard approach to managing professionals from a distance, to a tight-reined structure where the professionals manage themselves, in theory. In the former, it was easy for a clever professional with a little time on their hands to come up with crazy projects & work on them in their spare time (staying back) or in slow periods. It wasn't particularly encouraged, but there was an air of mad scientist about it.
In a modern methodology like scrum, this is less likely to happen. Pair programming means that when one person leaves for the day, the task is dropped; & there is less likelihood of having things on the back-burner, because we think in terms of getting things to "done", then moving on. Where is the opportunity to put something aside for "later"?

You could argue that that is exactly what refactoring stories & the like are for - except that they are planned in (& are usually the first to get shunted from the sprint under pressure). Therefore, the spontaneity, the creativity, etc, are somewhat dimmed or forced (refactor for four hours on the last day of the sprint). Some companies encourage their developers to contribute to open-source projects. Usually, this encouragement is carrot-&-stick: all open-source code used must be contributed to, religiously; only projects related to work are considered.

What is needed is more than a tentative understanding that a professional will, on average, use their time wisely & generate the product needed to keep the business going forward, & still have time to do "cool stuff" along the way - when they get around to it. There needs to be a formal process whereby people ask their manager something like "I want to spend half a day tweaking my widget discovery algorithm - you cool with that?" to get a languid "sure, but if you're still doing it tomorrow, you owe me some serious first-level support time".

It's a matter of trust & professionalism on the part of both the dev & their manager. It doesn't matter what the methodology is, this approach to treating people (employees) like adults, rather than machines, must benefit all.
You never know - that widget discovery algorithm might be the basis for a patent or a new product one day. Or you can just think of it as a learning experience that was much cheaper than sending someone on a course.

The Flyer

My wife asked me recently to help her make a flyer.You're wondering what this has to do with software, but by the time it was done, I felt like I'd delivered a major project, so I had to write this up as the retrospective.

She started by saying something like "I've already downloaded a program that's supposed to be good for making flyers." It wasn't. It was free. It came bundled with stuff that was useless & nigh-on counter-productive. Within the first few moments of using it, I realised that it didn't have the features I needed for the flyer, & it also didn't work well - it was poor quality. This was my first hint that this was a software project - management had decided on, & pressed, a technology that wasn't applicable for the problem at hand.

I then started a business analysis session - "What is the purpose of the product?". Her response was along the lines of "You know, it has to say ..." & she reamed off a few paragraphs of "essential features". Definitely a software project. "That's not all going to fit within the resource budget" I responded, referring to an A4 sheet.

This was going to take some true BA work.

• Who's your target user base?
• What's the product differentiater - the message?
• What's your distribution platform?
• How are you going to support the roll-out?

As usual, you have to ask the questions several times until you get a consistent answer.

Now came the first attempt to use the "proposed technology". Abject failure of the prototype. Definitely one to throw out, having learnt an important lesson.

Time to fall back on older, proven technology ... Powerpoint (or OpenOffice) may not be meant for flyers, but it works with the simplest of tweaks. No gimmicks, but solid, reliable functionality. Not only that, but I know I can turn it into PDF for distribution via email, or just print out myself.

About now, I was telling my wife to go away & leave me to it. This was a job for a professional developer, & QA wouldn't be necessary until the first release. I didn't expect this would be a multi-sprint feature epic, so I didn't feel that I had to rely on an iterative process. The product owner could easily decide that the task was done with the first release candidate. I was, however, prepared for continuous delivery - emailing her a PDF while she was wandering the house remotely with her tablet.

Tacit approval was assumed when no further issues were raised.

There was no release party, although I definitely deserved a cup of tea thereafter. I am yet to see if marketing (whose input could not be acquired in time for the initial design) can work with the deliverable as released.

Learning to Read Code

One of my junior co-workers asked me the other day for advice. They had inherited modules written by someone who'd recently left the company, & they were conflicted over whether to make drastic changes to the style & formatting, or just try harder to understand the code as it was so that the task at hand could be done.

   "How do you understand someone else's code without making it look like you're used to?"

Even if you have style guides, style checkers, automatic formatting, etc, there will be minor variations in style that can make code more in line with your own thinking, or small things that stand out as being "unreadable" that can taint the whole module. The classic examples are too much or too little comments, or too much or too little white-space. Note that these two, in particular, go both ways. It's a matter of personal preference.

No matter how much you work on Clean Code, a la Bob Martin, there will be tricks or approaches to a problem (even patterns) that you pick up in your career that are obvious to you, but will look strange & unreadable to someone else. Being aware that it might happen goes a long way to making your software more maintainable.

If you equate reading code to reading a book, for any given publishing market, the audience is essentially homogenous. As an author, you might aim for a geography & an age group (maybe a gender) or else a special interest. You more or less assume that anyone in that broad category will be able to read your book, & be able to understand what you have written - to appreciate it. The reality is that people always have favourite authors - a style or topics that they are more drawn to. Most people will also have authors that they just don't like - their style jars with them.

Reading someone else's code is exactly the same as reading a book that you didn't write. Some people write code that more people easily understand. Some write code that is targeted to a very specific niche audience - sometimes numbering one.

If you want your code to be maintainable, follow Uncle Bob's rules for Clean Code to get most of the way, but above all, remember that you are an author with an audience of coders who will read your work later.

If you want to approach other people's code to garner understanding - to maintain it - always remember that the author wasn't necessarily writing in your style, but you have to read it anyway, so look deeper for how they have gone about writing the code, how they are telling the story. The story is in there, because the code probably worked at some point. It is your job, as a maintainer, to find that story & understand it.

I can't teach you how, because I've achieved it through experience - voracious reading. There are no short-cuts to getting better at maintaining code. It just takes a lot more practice & a lot less wishing that the novel before you was as easy to comprehend as a Mills & Boone.

Technology Wars

A little while back, I started looking at a few different development languages. Each had its benefits & applications, which is why they came into existence in the first place. But, & here's what annoyed me, they each carried with them a justification that they were "superior" to any prior language, tossing about spurious claims about the limitations of some against the strengths of their favourite.

I say "spurious claims", because they sounded quite ridiculous to me, & I suspect anyone with real experience in the language under attack would agree. Sure, there is a level of comfort in the familiar, just as there is a daring excitement in taking on the new, but to then ignore these prime considerations & label one language as deficient because it can't do well a particular thing that a new language was designed specifically for, does seem to be drawing a long bow for justifying change.

Let me pick one such language, & I guarantee you'll be hard-pressed to work out which one it is:

•  It’s Perfect For Web Technologies
•  Saves Money
•  Saves Time
•  Active & Helpful Community
• Project not Handcuffed (to the original implementors)
• Build your own Plug & Play Apps
• The Big Players Use It
• You can use it too! (Personal & Professional use)

There you have it, the perfect language. Everyone should use this for web-based development. I'm sold - but which one is it? I suspect many CEOs would take this immediately, too.

This is what used to be referred to as a religious war. Once upon a time, there were only two or three great languages (religions), but now there is a proliferation. That's fine; I'm tolerant.


However, I have found the same sort of arguments creeping into other technologies within a development environment. The best revision control, continuous integration, IDE, etc.

Really - & honestly - it doesn't matter what the particular choice made is, but what matters is that you embrace that choice & follow through. You have to find the best way to use the technology at hand, become proficient, have effective processes in place that understand that technology, & continually review your processes & get feedback to learn from its use, innovate, & go forward.

I recently convinced management to standardise a team on IntelliJ to develop Java. I did this with minimal experience of IntelliJ, but with the knowledge that the team was spread across three IDEs! That was an intolerable situation that led to inefficiencies & basic time-wasting trying to get things to work in different environments, or supporting different technologies simultaneously.

Now, that team shares tips, fixes problems once (someone upgrades, tests, then gives the OK for the team to upgrade), finds plugins useful for everyone, & basically works together on the same problem from the same base level. I believe that the same could have been achieved using Eclipse or NetBeans with a similar effort - as long as it was only the one IDE.

Similarly, some complain that Jira "doesn't do what they want". That's just showing an inability to master a very simple & effective (but feature-rich) issue control system. There may be better ones, but Jira is, industry-wide, considered one of the good ones. Master the tech, don't let it master you.

Wrapping up, there are always good & bad choices for a technology, but there's usually a fine line between several good choices. At that point, put the religion aside & decide for the good of the team. Making a decision is what counts, not getting it perfect.

By the way, the "Eight reasons" was for Ruby.

Re: Productivity

I accidentally discovered Google's Go language recently. I really mean that it was an accident. As much as I like to discover these things, it's really a matter now of asking "How did this come about? Why did someone go to that much effort? What problem were they trying to solve?"

After a very short while, I had read that it was C-like, but it looked rather Python-esque. In short, it looked unintelligible, full of mystical short-hands, unstructured, arcane, & a veritable nightmare for maintainability. It's exactly what people are claiming as necessities for "better productivity".

I was aghast. How can someone be more productive when they can't fathom the code they wrote last week? How can having a faster compiler (or an interpreter) make up for the fact that you can't understand the code?

When I think of productivity, my first thought is an IDE. By that, I really mean INTEGRATED, I mean DEVELOPMENT, & I mean ENVIRONMENT. Maybe I need to elaborate. If there is a way to do everything in the one application, from design & (some) documentation to deployment & issue resolution, then it's integrated. User documentation is distinct - not a part of development - & issue tracking itself should be accessible from elsewhere (not limited to devs). There should be some consistency in accessing all of the tools that a dev uses - the databases, web servers, editors, debuggers, multiple languages, preferably across multiple environments (for a given project). That is the environment, which these days should support agile tools & methodologies like continuous integration, pairing, reviews, etc.

The IDE is what people (devs) use to be productive. Shortcuts, gestures, menu layouts, integration points, plug-ins, etc, are what makes the dev work better & smarter, without losing their train of thought or having to drop everything to do one small task with an independent app (or on a remote system).

No amount of fiddling with a programming language can ever replace familiarity with a well-set-up IDE & experience of developing in a given environment.

I started looking for comparisons of Go with other languages. I saw someone comparing the number of lines of code. Do people still do that? I can't remember counting code for quite some time - like in assembler, when you had a very small memory on board. Since then, a file of source has not had a limit, & my typing has improved. Better still, my IDE does most of the completion for me, so I don't have to worry about long names for imported features or matching my curly braces, etc. My IDE will even fix up the formatting for me later. It's that good. It's not that hard.

For those wondering, I have been an Eclipse fan for a very long time - even when it was absolute rubbish - because I believe that a real IDE is the only way to real productivity. I believe in it so much that I convinced my current VP-Eng to invest in IntelliJ so that the whole team has the consistency of environment that allows good dev technique to spread across the team.

It's at that point that I shall end this - if you're a lone wolf coder who uses EMACS, then you probably think that Go is a wonderful improvement on Visual Basic. That doesn't make it any more likely for me to hire you. If you're a professional team-player producing commercial-grade product, then you're unlikely to give whizz-bang programming languages a second thought.

The first thought is always - cool, I wonder if they came up with some new concept I could use in the real world? In this case, the answer is "no".

Behavioural Development

There seem to be a lot of seemingly-unrelated buzzword-oriented software development methodologies being flung about these days. Many of them have been around for a while, & I suspect that they've been so under the radar that anyone with experience expects them to be known, but someone who hasn't been keeping up will think of the concept as "new & exciting".

That's how buzzwords come about, in general. The people who use a concept when it is new come to a consensus on how to short-hand a long & complicated term that describes what they're doing, & then those not involved pick up the short-hand to use it as if they know what they're talking about, making it into a meaningless buzzword.

As an aside, I remember drawing a lot of networking pictures where we represented the internet as a cloud of unknown & unknowable infrastructure that "our servers" hung off. The cloud hasn't moved, only our perceptions have.

People are talking about BDD as a necessary skill for developers. Most people don't have a good understanding of what that really means.

Historically, BDD comes from 2006 when Dan North decided that TDD wasn't enough in itself. He started writing acceptance tests in the same style as user stories (Connextra, 2001). His implementation of JBehave, which developed into RSpec & then Cucumber over time (with David Chelimsky & Aslak Hellesøy), meant that specifications in user/system behaviour could be implemented & then become acceptance testing.

TDD had been around since 1999, with the test-first principle of the XP methodology. However, tests were usually based on use cases (Ivar Jacobson, 1986) - easier for devs to understand - rather than user stories (coming from BAs), which is where North's disconnect was. To this day, TDD tends to stay within dev-space, while BDD can extend across product development. The unit testing tool xUnit (JUnit, HttpUnit, etc) was Kent Beck's brainchild first for SmallTalk (1998), then Java (with Erich Gamma), thus causing the development of mocking (2003), dependency injection (2004 - Martin Fowler), etc, all to support both testability & acceptability of software solutions.

Enough history - all I really wanted to say is that BDD has been around for a long time, & it's only now catching on with the late adopters.

Now for the important bit - it doesn't matter what technology you use, what language you implement in, platform you develop for, methodology you espouse, or even effort you put into adopting industry best-practices. What really matters is the team's attitude towards the work itself.

BDD only works when you have an agile team which incorporates stakeholders in the daily stand-ups. It only works when the user stories are written up front in a non-technical manner by a domain expert (who is, or represents, the product owner). It only works when the behaviour of the team has been developed to the point where better product is the driver for adding features & proving their effectiveness.

The behaviour that should be developed is that given by Aslak Hellesøy - "[for a given feature] pop the why stack ... until you end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost"

Encourage an environment that allows every stakeholder in the product development process to ask that question (repeatedly).

Language Functionality

I like to think of myself as adaptable. Having said that, I've been living in the Java stack for quite some time & am perhaps too comfortable in a strictly OO world.

To prove adaptability in the extreme, I've taken to a functional bent with my programming. If you don't know why anyone would deviate to functional, some light reading might help:

• http://www.techrepublic.com/blog/software-engineer/when-to-use-functional-programming-languages-and-techniques/   

• http://www.javaworld.com/article/2078610/java-concurrency/functional-programming--a-step-backward.html

I decided to implement a problem in several languages that I am only now learning to use in a serious sense, each with some level of functionalism (picked at random):

• Java 8 (beta)
• Java with Guava
• Scala
• Ruby
• Groovy
• Python

I don't want to get into the nitty-gritty of comparing the languages, as such, because that's not the point, except to say that Java is not functional, & therefore adding the Guava libraries to it doesn't make it so.

I started each dev task with a perusal of simple tutorials to orient myself in the language. In the case of Scala, that was already aimed at Java devs (thankfully), & in the case of Ruby & Groovy, I left off the Rails/Grails bits for later.

I kept thinking "Oh, this language's approach is like that language except for ..." & then it dawned on me that each of the languages actually had their own distinct (if only slightly different) approach to doing exactly the same thing.
It got to a point of being annoying. I could take the structure of a Scala class & turn it into a Ruby class, & there would be line equivalences in almost all cases - but each line would be different. The symbols for making lists or maps or key-value pairs would have to change, the names of simple methods would change (key?, containsKey, etc), to the point where a cursory examination would elicit the question "How are these languages different?", yet a thorough examination would rather ask "WHY are these languages different??"

My answer? I don't know. I honestly don't. It's easy enough for a proficient professional to learn one of these languages quite quickly given another, but what do they gain in doing so? Most of the list have been ported to the major operating systems (with varying degrees of usefulness).
I even managed to get some joy out of developing my solutions from within the one IDE (eclipse with a lot of plugins, coercion & stress - & some loss of functionality).

But then, haven't we already gone through this - if you take C++ & Java, you can look at the implementation of methods & see strong correlations (fundamentally procedural), but the structure of a solution will likely vary because of specific things you can & can't do in their object-orientedness - inheritance being a classic difference.

My point? We keep trying to reinvent the wheel by using different materials to create smoothness or hardness or roundness, but it's still a wheel, & it's well past time we got on with inventing hover boots.

The Workspace Race

If you had asked me without pre-amble what I thought about open-plan offices, I would probably have answered that I had almost always worked in them. Within IT, it's very much the norm. In other office environments, it became a fashion for various reasons.

It makes sense in IT where there is a collegiate atmosphere - people collaborating on a project or related technologies, constantly in need of a few minutes interaction to verify an idea, even if they're not pairing up on the same task. There is no privacy, but the theory goes that you shouldn't need any. Open offices are great space savers, too, because you can pack more desks in.

The next step up is the good old cubicle, which gives you a sense of being cut off from the rest of the team - usually with your back turned to the place where people come along to bother you. Depending on whether it's a half-height (easily lean your elbow on the top to talk), of full (can only stick your head over the top), the cubicle walls are a barrier of mixed blessings. This is fine if you're not collaborating much, or if there are a lot of break-out spaces.

Then there's the office - a place where you can shut the door if necessary & block out everything but the fact that people keep walking past in the corridor. You can ignore knocks on the door, if you're lucky, or invite people in for an intimate chat. In IT, this is usually a great luxury.

The open plan works for IT, & it has a great history of working for different occupations down the centuries. We can easily imagine a Dickensian scene of accounting clerks tallying their numbers to a slight murmur of pages swishing & pens scratching, usually placed around the pedestal of the supervisor. We can also imagine a middle-ages scriptorium filled with monks carefully copying manuscripts with their coloured inks in precision, & the librarian available for consultation. Open plan.

I'm not suggesting that IT people are necessarily celibate or in need of constant supervision, but the idea of a space being open & littered with desks so that people share the experience while doing work that requires great concentration has a very long tradition.

I'll just throw in a bad example or two - imagine a 1950s secretarial pool with a sea of women typing up from short-hand notes at tiny desks, & the constant clatter of typewriters. Not my scene. Finally, a chicken farm, with rows on rows of confined birds doing the only task they know how (& have room for) - laying.

The modern equivalent offices are customer support & telephone sales people.

Understanding ergonomics & OH&S will not change the applicability of an office plan to its usage. There is never a "right" answer, there is just effective use of the space available. If you don't put that thought in, & review the results, & ensure that the reviews are meaningful, & act on what you've learnt, then there is always an impact. That impact is a decrease in productivity & increase in staff turn-over, usually - direct costs to the business.

Using the space for the purpose at hand is like choosing a methodology for product development. Throwing some furniture together & spreading resources about will never be enough to make a project successful. Open plan encourages open communication, but doesn't cause it. It is also true, though, that closed doors ensure that there is no communication.

The Full Story

A friend recently pointed out an article that said that presentations are slowly pulling away from buzzwords & bullet points to be more engaging by telling the full story. This means that the audience is using a much more receptive part of their brain.
I was reminded of an old cartoon (strangely, I don't think it was Dilbert) where someone plays buzzword bingo during a presentation. That's about as exciting as it gets sometimes when someone presenting is simply throwing their viewpoint at the audience to either justify their existence, or else prove how clever they are. I'm not saying that consultants are the main culprits...

This is in line with how software development has been moving from requirements that read like bullet points ("name entry field must be twenty characters") to use cases ("the user enters their name; the entry screen validates the length; the database stores it in a field") to user stories ("as a user, I want to provide my full name, so that it is stored in the system"). Well written requirements are cutting out the "translation" steps from analysis to functional specs to design, etc, causing the developers to understand how the system really works with respect to the user, & ensuring that developers & testers are working to the same end goal throughout - they're using more of their brain.

Going back to presentations as a story - if you have a mixed audience, you tend to either dumb down the bullet points to the lowest level, or else ignore that sector & pitch directly at the money men. Telling a complete story (the old-fashioned way) means weaving into context the ideas that you want to get across, & also taking non-verbal feedback from your audience (fidgeting, worried expressions) to change gears & ensure that your ideas sink in.
It used to be accepted that only ten percent of a presentation (or a university lecture) is actually remembered. Why is this acceptable? Why waste your time giving the whole presentation when you could stop at the first yawn? If you engage your audience more, then maybe twenty percent will sink in - doubling your chance of a sale/investment/interest/support.

The same goes for software development. A two-hundred page spec written by a BA that gets translated into twenty different people's implementation of functions & tests is guaranteed to fail, because there is no consistency of interpretation. You cannot make a bullet-point spec so interesting that people will want to go back & re-read the fine detail, so they'll read once, hope that they have it clear in their head, & never go back to it - ninety percent loss of information.
A user story, however, relates to one piece of behaviour in a given context, clearly stated. Once that behaviour is correct, there is no going back to re-read, there is only (automated) regression testing.

User stories & TDD (test-driven development) or else BDD (behaviour-driven dev) speak directly to the BA's audience. Of course, the best way to do this is within an environment that fosters co-operation, so I do mean an agile methodology.

Hereafter, the person telling the story is not an external consultant proving how clever they are, but a part of the team who all want to know what the full story is.

Curves Ahead

When you're driving at speed & you see a sign that says something like "Curves Ahead", it's a good time to slow down.

When you're on the bleeding edge of technology & you're ahead of the curve, the trick is to maintain speed, hang on tight, & ride it out.

In a way, the same thing is generally at stake - your future. Drive too fast & you won't have one. Make a wrong technology choice & you won't have one. The difference is that very few people drive in a competitive market.

Getting ahead of the adoption curve is very risky, & it doesn't always pay off. There are often choices that get made way back in the journey that don't let you change the technology route. If you're developing for the iPhone/iPad platform, the question is not if you'll support the recent iOS release, but how soon you can - how fast you'll take the curve - because the customer base is ahead of you.

But there are some choices that can wait - like supporting new standards before they're implemented. It's great to have a tinker with Java8, but try to incorporate it into your IDE, let alone hoping it will work reliably in beta. What about HTML5 & CSS3. Everyone seems to want to develop ahead of the curve, but in this case the customer base isn't really there yet because browsers aren't fully compliant & users are notoriously bad at upgrading their browser anyway.

Being in a beta program is a great way to look around the curve & influence the landscape ahead, but you don't want to drive around a blind corner to discover that the road hasn't been built yet. I remember Bullant Technology, & how it was going to revolutionise the web with high-speed transactions. Whole companies drove off that cliff.

Professional drivers use their experience & develop techniques to stay on track & stay alive. Professional technologists rely more on luck & gut instinct to live by the choices they make. If they fail, they move on to another race. Can we measure the success of a technology driver? Can we see how the championship points table stands?
At least that sounds easier than looking at the manufacturers' points table - they tinker with the technology vehicle so often it's hard to tell what's being driven at the front of the race.

Abusive Language

Sorry to disappoint, but this is actually about Java8.

A long time ago, I was an academic, & we used to teach object-oriented programming in C++. How naive! This was when Java was a mere pup, so it wasn't really an option. The important thing was teaching object-oriented-ness (in theory) & then showing the students how to use it in practice.

Years later, I went from being a C++ developer to being a Java developer - during the war. No, I don't mean a military conflict, but the point when those two languages had some commercial altercations. Propaganda leaflets were dropped from skyscrapers with strident calls for "Multiple inheritance!", etc. There was a lot of discussion over maintainability, libraries, the friendliness of the language (readability), the viciousness (the ability to write bad code), etc. In the end, Java "won out" because it was more web-oriented, & then a lot of the C++ world turned to C#.

A few years ago, I was introduced to Scala. Without delving into it commercially, I could see that it had become an academic favourite because it was a way to do functional programming - which represents theoretical ideals - & it also runs on the JVM, which makes it Java friendly & more useful than Haskell. At the time, I thought "nice theory". I couldn't see how functional was going to take the commercial programming world by storm, or how a new language would fit in. Who wants it?

Now I've got my dev copy of Java 8. Each of the previous major upgrades has been an improvement - some in efficiency of the JVM, some in better coding style. Up until now, though, the introduction of generics, which was effectively C++ templates a long time overdue - was the biggest change to the way Java is used. Some would say that annotations were as big a change, but this depends on whether you take advantage of frameworks (Spring, Junit, ...).
Java 8 has Lambdas.

Although you might think that anonymous classes & defining callback interfaces had already covered this area, it was messy, so you avoided it. Now, there is encouragement to be functional. It will be easier to write functional code within object-oriented Java. You will discover that you'd been doing it quite a bit before (in event handlers) & can do it better & more often.

Here's the kicker, along with the new way of writing lambdas (which is VERY concise) come other short-cuts influenced by Scala & Ruby that do seem to take away some of the elegance of Java - where verbosity was often a blessing. I can recall, during the war, how we were told to avoid inline-conditionals, on the basis that they made code unreadable. Now we have inline functions.

Is there a driver for making things easier or quicker to type? I thought that's why we used IDEs with short-cuts. Good code design & development can be partially auto-generated from UML (theoretically), then the features defined in TDD before the implementation is begun. XP's mantra of pair programming is distinctly on the side of "think before you type".

There has to be some balance between introducing new language features that work elsewhere (lambdas, generics, annotations) & staying true to how that language is used professionally (readability, testability, design).

In the world of written & spoken languages, some countries have committees that ensure the "purity" of the culture represented by the language. In Java, we have Oracle & OpenJDK. At some point, you have to ask whether new concepts need to be incorporated into the culture, or whether they would just be an abuse of the language.