Feed aggregator

Learn to Fully Leverage JavaServer Faces

Javalobby Syndicated Feed - Mon, 29-Jan-18 22:01

<!-- Google Tag Manager (noscript) --> <iframe src="https://www.googletagmanager.com/ns.html?id=GTM-PDSRGWC" height="0" width="0" style="display:none;visibility:hidden"></iframe>

The focus of this article is to introduce and explain the JavaServer Faces framework.

Categories: Java

Defending Public-by-Default in Kotlin

Javalobby Syndicated Feed - Mon, 29-Jan-18 14:01

Some people have spoken against Kotlin’s decision to make classes, methods, etc. public by default (when no visibility modifier is used), and I would just like to pitch in on why I think JetBrains made the right decision on this one.

Those who are against it bring up the principle of hiding everything that you can get away with in order to preserve encapsulation, and that if it’s too easy, people will make things public that shouldn’t be. I can see their point, but I don’t think it’s as likely to be to an issue as they seem to think.

Categories: Java

What’s New in IntelliJ IDEA 2018.1 EAP?

Javalobby Syndicated Feed - Mon, 29-Jan-18 10:01

Last week, we opened the IntelliJ IDEA 2018.1 Early Access Program, and we hope you have already given this new version a try! Today we’re publishing a brand new IntelliJ IDEA EAP build. Download the latest EAP build via Toolbox App or get a copy from our website. Read this blog post to learn about all the new features this EAP build has prepared for you.

The improvements are coming for the Spring Boot framework. Now, after you run a Spring Boot web application, a new icon is shown in the gutter for methods with @RequestMapping annotations that handle incoming HTTP requests. By simply clicking this gutter icon you can open all mappings in a scratch file with an .http extension and perform an HTTP request in the editor via the new REST client.

Categories: Java

Lambda Calculus in Clojure (Part 2)

Javalobby Syndicated Feed - Mon, 29-Jan-18 04:01

In Part 1, we worked with boolean algebra using Church Encoding. In this post, we are going to reuse some of the previous work to build a similar system, this time for numerals.

Church Numerals

In the algebra we built in the previous post, Church booleans were encoded using higher-order functions. The way Church numerals are represented is similar: given a number n and a function f, the Church numeral of n is the number of times fencapsulates n. For example, for n = 3, the function f encapsulates n three times:

Categories: Java

DRY in the 21st Century

codecentric Blog - Mon, 29-Jan-18 02:30

It seems that nowadays, the “Don’t Repeat Yourself”(DRY) principle is one of the foundations of programming that is criticized the most. You can find tweets and blog posts questioning it. Also, it seems that critical voices are increasing.

But why is this happening right now? DRY, amongst other principles, is often used when distinguishing good from bad code. To me it was taught at university as an extension of SOLID (making it SOLIDD basically). The principle itself is easy to understand and apply. Examples showing the importance of the principle can be found all over the Internet. Still, there is some rejection.

I would like to offer my opinion here and state why I do not agree with the critics completely. But first, let’s start by looking at where and when the DRY principle was formulated.

The Pragmatic Programmer

As Wikipedia tells us, DRY was firstly formulated in “The Pragmatic Programmer” [1]. In chapter 7 “The evils of duplication” (pp. 26-33) the DRY principle is formulated as

“Every piece of knowledge must have a single unambiguous, authorative representation within a system.”

The authors also mention that

“[…] it is one of the most important tools in the Pragmatic Programmer’s tool box.”

As pointed out by several people, the principle is about “knowledge” – not code, not classes, not methods, not functions,… The principle is basically agnostic of code. But if we keep on reading the book we see that for the authors code is also a form of knowledge; next to comments and documentation. So, whoever points out that DRY is not about code at all did not read the complete chapter. Or, as programmers like to say:

The truth is in the code.

And therefore the knowledge is in the code.

Following reasons for duplications and their explanations, the authors point out that we should “Make it easy to reuse” our code. Regarding the structure of the book, this tip (all of the advice in the book is presented as tips) is as important as DRY, it just did not receive such a nice abbreviation (MIETR is hard to pronounce I guess). So, for the following discussion, I want to look at DRY and MIETR.

Historical Context

Talking about the Pragmatic Programmer, it is helpful to take a look at the time when it was written. Published in 1999, it will see its twentieth birthday next year. Regarding the rapid development in Computer Science 1999 might not be the Stone Age, but something like the Renaissance. Since I was more interested in my PlayStation back then, I asked my older colleagues what some of the hot topics those days were:

  • OOP
  • JavaScript
  • PHP
  • J2EE
  • CVS

Next to the technological aspects, there are also some other things worth mentioning:

  • Java 1.2 was the most recent Java version.
  • The Internet Bubble was still rising.
  • Netscape lost the Browser Wars.
  • The Apache Foundation was founded.
  • Apache Ant and Maven were not invented yet.

So what can we say about this time? The majority of applications were monolithic. Vertical scaling dominated over horizontal scaling. OOP was probably seen as the solution for all problems (which lead to huge class hierarchies, which we try to solve now by favoring delegates over inheritance). Building/packaging applications was most probably a bigger issue than it is nowadays.

All in all, I would say that reusing code, either within a project/company or outside of it, was a much bigger problem in 1999 than today. No Apache, no GitHub, SourceForge just started. I do not want to imagine having the problems of unreliable dependencies that you cannot look into because some closed-source library was bought from some vendor. Copying everything into big /lib directories is also an issue from the past.
In this context, having code that is easy (and fun) to reuse might have been a rare occasion. Therefore, raising developers’ awareness of MIETR seems more important than advising them to follow the DRY principle.

Having seen the past, let us go back to today.

Microservices, DDD, Serverless…

What we can easily agree on is that times have changed since 1999. Nowadays, we have Microservices or even Pico- and Nanoservices. Using a serverless approach for an application is also rising to the top on the Gartner Hype Cycle. Splitting your application into its domains and bounded contexts is also more mainstream these days.

From my point of view, as Microservices rose up, skepticism about DRY increased, too. Sharing code between different Microservices is considered bad (not without reason, of course). But still, extracting code into a shared library also encounters resistance, even within a project. So, the solution is obvious: code has to be copied. And this violates the DRY principle. One could argue that by trying to make DRY irrelevant, developers only try to retrospectively justify their code duplication, since they were either too lazy or too ignorant to create a shared library. But I think this argumentation falls short.

Philosophically put, the problem might be within our education as developers. Everything is binary, DRY is either ON or OFF. There is no 30 % DRY. MIETR is not (easily) measurable, and what we cannot measure, we cannot control and therefore is ignored.

Having the current context and a philosophical thought, let’s take a look at some concrete examples.

Examples

In this section we will take a look at two examples to see how DRY helps us keep our code clean. Hopefully, I can convince you that the application of DRY, at least in those examples, is advantageous.

UriComponentsBuilder

A class that I have used a lot recently is the UriComponentsBuilder. This class helps us transform a URL with placeholders like http://{host}:{port}/{username} into its expanded form http://localhost:8080/admin. Additionally, it can add query parameters to the request.

If I was not using this class, I would have to implement my own string replacement logic. And this replacement logic would have to be copied across all places where I would need a URL with placeholders. Changing e.g. the markers of a placeholder to something different than braces would require a lot of changes in the code. Of course I could create my own Helper/Util/… class that contains the replacement, but this would be DRY, nearly as DRY as using the Spring class.

But why would I want to violate DRY here? This class serves me very well. MIETR is also “high” because the API is well documented and I can use the class without looking into its internals.

Table Name

Another example would be a table name that I need in my code. Following the recommendations from The Pragmatic Programmer, I would create a constant somewhere in my code (or even extract it from the SQL file that creates it) that contains the table name. Whenever I have to access the table, I use the constant. If the table name changes, there is only a single place where the code has to be changed. Again, simply following DRY. Without this constant, several files would need to change in case of a renaming. This would be quite error-prone because I could easily forget a place to change it (and according to Murphy’s Law, I would). Importing a constant somewhere in my code is also quite easy to do, so MIETR is taken into account, too.

Putting DRY into Context

I hope that you agree with me so far on the DRY principle.

Of course you might argue now that those are only technical examples. The UriComponentsBuilder is a helper regarding my HTTP communication and a table name is also technical, nothing businessy. But still, they represent knowledge. The knowledge about what placeholders in my URLs look like and the knowledge about the table name.

So, to put it in a more abstract way, within the context of URLs, the UriComponentsBuilder is my single source of truth for replacements. And within the context of my database, the constant with the table name is the single source of truth for that name. I got to admit that my knowledge in this area is rather limited but this sounds like a Bounded Context to me.

So, what if – and only if – we should no longer apply DRY “globally”, but rather within a Bounded Context?

Why DRY is still relevant

In my opinion we will return to darker times if we start praising the rejection of DRY as being a trait of experienced programmers. The principle is still relevant and should be taken into account when writing code.

What I also think is that we should adjust DRY to the current times. If your shopping application needs to represent a customer in the context of purchase and in the context of shipping – go on, copy it. Create two customer representations. As the DRY opponents state, those two representations will differ more and more over time and forcing it into the same class for the sake of DRY would cause more harm than good. Or, as the author of “Domain Driven Design” [2] stated (p. 344):

“Code reuse between Bounded Contexts is a hazard to be avoided.”

Also, if I have to instantiate an object with parameters I only use in half of my application or which I set to null just because something has to be passed into the constructor, it is no convenient reuse. It is rather a burden and a possible source of errors.

Blindly applying DRY is as false as ignoring it. I personally like the rule of thumb that if something occurs identically three times or more, then it should be refactored and stored in a common place.

To summarize, apply DRY within your context or unit of deployment. Don’t DRY out everything up front but rather look for reccurring patterns. And if you extract and abstract something, keep MIETR in mind.

Lastly, to repeat myself: Don’t repeat yourself within your context.

References

[1] Andrew Hunt and David Thomas. 2010. The Pragmatic Programmer: From Journeyman to Master. 25th Edition. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
[2] Evans. 2004. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

The post DRY in the 21st Century appeared first on codecentric AG Blog.

Categories: Agile, Java, TDD & BDD

Functional Programming: Functions

Javalobby Syndicated Feed - Mon, 29-Jan-18 01:01

In the previous posts, we took a look at how functions are the core pieces in functional programming languages. We talked about pure functions, referential transparency, side effects and recursion in the previous posts. In this post, we are going to explore some properties of functions and how we can use them in a functional programming language.

Function Definition

A function is a black box that, given an input, always gives you back the same output. As we stated before, a function does not have any side effects; if it has any, it could be a procedure, but not a function. Function is a term that comes from mathematics, and there is no concept of side effects in there. A function accepts a set of input values; we call that the domain of a function. The output of a function is called the codomain and the set of outputs is called the image of the function. We can decompose them like this:

Categories: Java

Immutable vs. Unmodifiable in JDK 10

Javalobby Syndicated Feed - Sun, 28-Jan-18 22:01

Nearly two months ago, Stuart Marks wrote, "Immutability is like wine." He then reminded readers of Schopenhauer's Law of Entropy: "If you put a spoonful of wine in a barrel full of sewage, you get sewage. If you put a spoonful of sewage in a barrel full of wine, you get sewage." With that provided background, Marks applied Schopenhauer's Law of Entropy to immutability with "immutability" replacing "wine" and "mutability" replacing "sewage" to make this insightful observation:

Similarly, if you add a little immutability to something mutable, you get mutability. And if you add a little mutability to something immutable, you get mutability.

The context of this quotation is an online discussion starting in October regarding JDK 10-targeted JDK-8177290 ("add copy factory methods for unmodifiable List, Set, Map") and JDK-8184690 ("add Collectors for collecting into unmodifiable List, Set, and Map"). JDK-8177290 is a subtask of JDK-8156070 ("Immutable Collections enhancements"), which is described as "a container for various enhancements and improvement subtasks for the immutable collections."

Categories: Java

Simulating Split Brain Scenarios in an Akka Cluster

Javalobby Syndicated Feed - Sat, 27-Jan-18 23:01

With the microservice revolution, the idea of having small services that can be easily scaled up or down to handle different loads has flourished. This brought about the need for services to have their own cluster and be responsible for managing it.

But managing a cluster is not a simple task — many things can go wrong.

Categories: Java

Super-Fast Statistical Queries in Java

Javalobby Syndicated Feed - Fri, 26-Jan-18 23:01

Many organizations have enormous values in data stored in relational databases, but it is often slow to analyze. Calculating things like correlation coefficients or analyzing trends can take many minutes or even hours using a regular SQL database. Wouldn't it be nice to be able to do it in seconds or even in milliseconds?

As some of you know, Speedment is a modern Java ORM that is built around the new functionality of Java 8 and 9, like Streams. The enterprise edition allows Java developers to easily run typesafe queries on an off-heap in-memory view of the data, without running into garbage collect limitations even when aggregating hundreds of millions of rows. In this article, I will show you some nice examples of analytics that can be performed using these tools.

Categories: Java

Lambda Calculus in Clojure (Part 1)

Javalobby Syndicated Feed - Fri, 26-Jan-18 14:01

Lambda Calculus is the smallest programming language. As we saw in my previous post, the only building blocks available are functions, variables, and expressions. There are no built-in primitive values or operations. How can we then solve real-world problems using Lambda Calculus?

In this post, we are going to create a set of building blocks, using lambda expressions, to calculate boolean expressions. For this, we are going to use Clojure, which is a dynamic functional language based on Lambda Calculus.

Categories: Java

Desktop UIs Will Stay Alive Thanks to Web Technologies

Javalobby Syndicated Feed - Fri, 26-Jan-18 10:01

To understand what’s wrong with Java desktop apps, let's take a look at the new features of JavaFX, a leading UI framework for desktop applications. It becomes obvious that it is trending towards the web approaches, borrowing more and more features from the web world. JavaFX supports a subset of CSS features, accompanying it with their own properties.

However, this all is far away from what the web offers for UI. Another essential aspect is tooling. Have you seen anything in any way similar to developer tools coming along with all the popular web browsers for desktop UI design? Finally, as JNLP goes deprecated in Java 9, it certainly doesn't add points to desktops.

Categories: Java

In praise of SWARMing

Dan North's Blog - Fri, 26-Jan-18 06:56

Most of my work these days is helping organisations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.

It is into this space that a new generation of software methods have emerged. SAFe, LeSS, DAD and others claim to help enterprises “scale agile,” whatever that means. A generous interpretation is that people who have a track record helping organisations on this journey have managed to codify their knowledge into a set of blueprints, guidelines, frameworks and methods so you don’t have to. Another take is that execs in organisations above a certain size like to buy a packaged solution to a perceived problem, and people with experience in selling to this market know exactly how to dress something up to look sufficiently appealing.

The most successful transformations I have experienced—the ones where you walk into the office and there is a tangible difference in the energy and interactions between people, where the commercial and management stakeholders are as excited and invested as the technology stakeholders, where everyone agrees on the metrics that matter and those metrics are trending in the right direction, where the people involved are proud to be part of the change, and where those outside are eager to get involved—those transformations succeed because a small cabal of dedicated individuals take the time and effort bringing people on the journey with them; they create and nurture a groundswell of enthusiasm; they engage, challenge, educate and support the middle and senior managers whose world is being turned on its head; they gain the executive sponsorship and investment to carry the whole thing forwards; they use external help because they know they can’t do it all themselves. And they do all this without recourse to canned methods or certification Ponzi schemes.

I think this approach deserves calling out so I am offering a new acronym, SWARMing: Scaling Without A Religious Methodology. My argument isn’t that packaged scaling methods are unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation. They can be anything from a useful starting point to an expensive distraction, but one thing they are not is a solution.

No silver bullet

The hard truth is that most lean or agile transformation initiatives will fail, because they challenge the very fundamentals of the organisation: how the money works, how governance works, how management works, how accountability works. These transformation programmes tend to happen in 3 to 5 year cycles. With each change cycle a senior manager adopts the latest iteration of words and rituals without taking on the hard work of engaging with the organisation’s underlying structures, behaviours, values and beliefs, and three to five years later the latent constructs have prevailed. The only tangible results are a large transfer of cash to the external consultants, a rash of certificates with a recurring revenue model, and a metaphorical shrug of the corporate shoulders. The inevitable hand-wringing that ensues and the need to do something precipitates the next change cycle, and the wheels turn once again.

Transformation is not a transactional activity that starts and ends and has a budget, and it should not be treated as one. It is never finished, in the same way evolution or adaptation is never finished. The goal is rather to break free from the thinking that led to the incumbent system by introducing a new paradigm, and then to use this to achieve a new steady state where the organisation is responding quickly and effectively to external and internal feedback, behaving like a genuine learning organisation. The challenge is to encourage, precipitate, and then support that paradigm shift. The principles underlying the new model are straightforward to describe, but they involve a root-and-branch rethink of the fundamental structures of the organisation.

I see a number of factors necessary for genuine, measurable, lasting transformation. Where I’ve seen transformation attempts fail, one or more of these has been conspicuously absent. Before I discuss these I want to explore some of the differences between the old world and the new, and look at what makes these packaged scaling frameworks so appealing.

The shape of waterfall

A paradigm is the set of assumptions or beliefs we hold to be true. Over time we institutionalise these into corporate policy, organisational structures and even into law, as I have discussed elsewhere.

I want to highlight some of the differences between the old and new paradigms to show the ground we have to cover. In each section I first describe the traditional paradigm and then the corresponding assumptions in the new world. As you read each paragraph, whether or not you agree with the statements, remind yourself that these organisations are acting as though they are true.

Cost efficiency: utilisation vs flow

In a traditional firm the organisation is seen as a number of separate departments, each of which is either a cost centre, like IT or HR, or a profit centre like Sales. The difference is that a cost centre doesn’t contribute directly to revenue. Costs are allocated to each cost centre, and cost efficiencies come from reducing the operating costs in the cost centres and maximising the revenue from the profit centres. Common strategies for reducing costs, especially towards the end of the financial year, are limiting travel, reducing variable headcount by laying off contractors and other temporary staff, shifting work to cheaper countries or locations (“moving the work to the people”), repurposing legacy hardware and equipment, and forcing teams to use standard components to minimise “cost per use”. Common strategies for maximising revenue are offering commissions on sales, setting aggressive quarterly targets, and offering incentives and rewards for achieving specific goals. Gains come from maximising resource utilisation, i.e. keeping people busy.

In an agile organisation—in the broader sense of business agility—the organisation is seen as an interconnected system where all departments are value-generating, either directly contributing to the final product or indirectly enabling the organisation to work more effectively. Value chains map the creation of value through the organisation, ending with meeting a specific customer need. Costs and revenues are allocated holistically across the whole value chain, and cost efficiencies come from optimising the flow of value. Common strategies for reducing costs are identifying and eliminating non-value adding activities, limiting the amount of work in process to reduce hidden inventory of work, and assembling multi-disciplinary teams to reduce handoffs and other delays (“moving the people to the work”). Common strategies for maximising revenue are working iteratively and incrementally in small batches to realise value sooner and improve Risk-adjusted Return on Capital, frequent testing of product ideas with customers to identify which work not to do, and enabling teams to choose the most effective tools to reduce their time to market. Gains come from optimising flow efficiency, i.e. keeping work moving.

Managing work: project vs product management

In a traditional firm scope is defined in detail and locked down before the work starts, usually as the result of a project or programme initiation exercise, in the form of a Business Requirements Document as part of a Business Case, which will also contain a cost and resource breakdown and revenue projections. This is presented to a funding board and the programme budget is allocated and signed off. Success is defined as delivering the agreed scope within the cost and time constraints. Variance in scope is frowned upon, as is replanning, which can have severe knock-on effects elsewhere in the organisation.

In an agile organisation scope is defined dynamically within a product area, usually in terms of moving a business metric in a desired direction, for instance reducing customer churn or increasing profit per customer visit. Funding is allocated as an ongoing run rate for the product area, and revenue is tracked as a near-term trailing indicator. Success is defined as the ongoing achievement of the business metric goals, or learning through evidence that this is the wrong strategy. Variance in scope is both expected and encouraged, and regular replanning based on market and operational feedback is normal.

Portfolio planning and governance: up-front vs ongoing

In a traditional firm the annual plan is sacrosanct. People up and down the organisation invest considerable time and effort in the annual budgeting and planning cycle. Each department predicts what it will spend and what it hopes to achieve, and a central body determines each department’s budget. These budgets cascade into the programmes and projects within each department and a centralised PMO or similar function monitors and polices progress. Replanning has a high cost and effort and is discouraged, so there are repercussions for deviating from the plan once it is underway. Projects and programmes are assessed as Red, Amber or Green (“RAG” status) according to their level of deviation from plan, and the project and programme managers are held to account accordingly.

In an agile organisation financial planning happens more frequently, typically using a rolling one year plan reviewed quarterly. Many firms are adopting OKRs as a mechanism for this. The PMO supports global system optimisation: Green means things are good; Amber means a project or programme needs help with a decision that has implications beyond its boundary; Red means the lack of such a decision is putting the outcome materially at risk. “RAG” status in this context is about how well the project or programme is being supported by the wider organisation.

The appeal of frameworks

There are other contrasts I could draw but the above should serve to illustrate the cultural and organisational chasm we face and highlight the work ahead of us. Sociologist Ron Westrum goes into more detail about different organisational cultures but these are some of the more common differences I have encountered.

Packaged frameworks are appealing because you can easily find this overwhelming. You want this Business Agility magic you keep hearing about but you don’t want to, or are unable to, challenge the corporate funding and governance processes, and whatever you do has to fit within strict departmental cost controls. So you start by sending a handful of project managers for Scrum Master certification, and maybe some business analysts for Product Owner training, then you try Scrum for a bit. Later you might try Scrum-of-Scrums, SAFe, LeSS, or similar with the best of intentions. If you can just to prove it works in a contained pilot environment, the rest of the organisation will surely wake up and beat a path to your door!

The problem is that this kind of transformation requires a fundamental shift in how people think and how they operate. This in turn requires acknowledging that the way they are running things is based on assumptions and constraints that are no longer relevant to the modern business environment; that they are still in business in spite of, rather than because of, these inherited management and governance systems. No one likes to acknowledge that, even to themselves. Their subconscious minds vehemently resist this paradigm shift, which makes them easy prey for a vendor selling a product that promises said transformation while conveniently fitting their existing paradigm.

The vendors and consultants can do this regardless of whether it will deliver the results, safe in the knowledge they and their methods won’t be held accountable if it doesn’t, because the one thing everyone can agree on is that transformation is hard and at least we tried. Many proponents of these methods have a religiosity about them. Their method works; if you don’t believe this you are misguided, misinformed, or just antagonistic (I’ve been accused of all three); and if it doesn’t work then you are applying it incorrectly.

Scaling Without A Religious Methodology

There are a handful of ingredients without which you are unlikely to achieve lasting change. They are by no means a formula for success. Rather, you should consider the absence of one or more of these a danger sign, a significant risk to be managed and mitigated.

1. Time

Transformation takes time, patience and tenacity. Shifting a large enterprise of thousands or tens of thousands of people will take a number of years. The technology adoption lifecycle applies here, with its pioneers, early adopters, early and late majority, and laggards. You should focus your efforts on the pioneers and let their successes draw in the early adopters, and so on. Too many transformation efforts try to reach everyone at once—”We are going agile from Monday!”—and the social demographics show that this just doesn’t work. You should expect no more than 5% of your organisation to be pioneers of this kind of change, so work on identifying and recruiting them, and giving them the environment and tools they need to succeed.

2. Investment

Just as this transformation won’t happen overnight, it also won’t happen on its own. You will need to assemble a dedicated team, which means ring-fencing and funding them, and delegating or managing their responsibilities. In the greater scheme of things this is a tiny investment—you can get a long way with a handful of people—and I am continually surprised at how difficult it can be to get this allocation of people and funding in an organisation that clearly wants to go on this journey. It is worth taking the time to ensure this commitment is in place before you get going, however long it takes.

3. Communications

Different audiences respond to different messages. Take the time to understand your stakeholders and think about the kinds of communication they will find useful: Which channels? How often? What content? What is the goal of each communication? How can you meet them where they are? Where do you want them to be? Where are the gaps? From awareness roadshows to executive briefings, the way you structure and communicate your vision, aspirations and progress will be most people’s primary view into your world.

At the very least you should be able to answer “What’s in it for me?” and “What do you need from me?” for every stakeholder group. As well as the people you will be directly interacting with you should also consider anyone indirectly affected by the transformation. These could be internal and external suppliers, customers, partners, regulators, auditors, or anyone else

You will have your share of detractors, primarily the late majority and laggards who have a vested interest in maintaining the status quo, and who will be anything from indifferent to critical to actively sabotaging your efforts. And don’t be surprised to find allies in unexpected places. Amplifying your successes and neutralising your opposition can take up a lot of your time so having a robust communication plan in place will help you stay on track and not lose sight of important stakeholders.

4. Influence

More than anything else your core team needs both the ability and the credibility to influence up, down and across the organisation. Trying to do things on your own will be like boiling the proverbial ocean. You are trying to create a groundswell and encourage change, not do it all yourself. You need the requisite executive sponsorship, and people who are not afraid to speak truth to power, respectfully and professionally, and who know when to shut up and listen.

Some years ago Lean Operations veteran Richard Durnall wrote an article describing the arc of transformation an organisation goes through. That link is a slide from a talk I gave that includes a discussion of this arc, because Richard’s blog is no longer online. He describes six stages of transformation in terms of things that break. You start by introducing new ideas that challenge incumbent beliefs (“The people break”). Soon you find the processes and tools are no longer fit for purpose (“The tools break”). Measuring flow of value rather than busyness and effort brings you into conflict with the PMO (“The governance breaks”). As you start to scale you realise just how many stakeholders you need to bring on the journey with you (“The customer breaks”). Shifting to product rather than project management means you need regular incremental funding rather than infrequent, big investments, which the corporate finance model isn’t set up for (“The money breaks”). Finally you realise that silos of functional departments are exactly the wrong structure for business agility (“The organisation breaks”).

The two most challenging stages are around the governance and the money. This is where corporate structures, policies and culture are likely to be the most ingrained, and where you will potentially encounter powerful friends and adversaries! The sooner you can start to influence the governance and finance elements, the greater your chances of lasting success. Conversely if one or both of these are outside of your control, your potential sphere of impact will be correspondingly smaller.

5. Information

There are some core fundamentals that you and your pioneers will need to learn, practise and internalise. My starter list would include understanding the basics of Theory of Constraints, Systems Thinking, Throughput Accounting, Complexity Theory, Lean Product Development, Continuous Delivery, modern leadership, and change. If you are a book learner you can glean most of this from a handful of well-written books: The Goal, Thinking in Systems, Lean Enterprise, Continuous Delivery, Turn the Ship Around, Fearless Change, and for extra credit, The Principles of Product Development Flow.

The key here is understanding the core principles without getting bogged down with specific implementations. This is where those scaling frameworks can be helpful, as a “non-blank piece of paper” to demonstrate to your sponsors that you aren’t just making this up, and to provide an initial vocabulary. But take the time to understand the principles behind the methods and techniques so you can adapt them to your own context.

6. Practise

“Knowledge without practice is useless. Practice without knowledge is dangerous,” says Confucius. Reading about these topics is like reading about scuba diving or surgery. You won’t appreciate it until you do it for real, and like any new set of skills it will take time to get good at it. Messing up is a necessary part of learning. You should therefore think about how to practise in a safe-to-fail way. That conversation you want to have with the CFO about releasing smaller amounts of funding more frequently with less of the heavyweight approvals boards and governance theatre? You should probably practise that first on a friendly finance stakeholder who will politely let you know they glazed over as soon as you mentioned velocity and story points. And that they don’t think the CFO will appreciate the phrase “governance theatre.”

In the words of a famous Swedish poem, you should speak with farmers in farmers’ words, and with learned men in Latin, in other words practise adjusting your message to your audience. Likewise try applying flow tools like value stream maps, lead time measurement and cumulative flow diagrams on a small, friendly project first, before you try to roll it out across the wider programme. Gather evidence before you pitch flow metrics to the PMO. You may only get one chance.

7. External help

My favourite definition of a good consultant is someone who has screwed up enough times before on someone else’s dime that they don’t have to do it on yours. You can go it alone but you are likely to fall into all the traps everyone falls into, and your fundamental attribution error bias means you won’t believe me. There are two kinds of external help that seem to make a real difference: trusted advisers and embedded coaches. The former will be invaluable early on and should become less necessary over time. The latter you want to engage as you start to build momentum and realise you can’t be everywhere at once. The problem is that anyone can declare themselves an agile or lean coach just by updating their LinkedIn profile—around 18,000 at time of writing—so it is worth shopping around and doing the due diligence. Use your network—word-of-mouth recommendation and track record are by far the best

As you start to build momentum you don’t want an army of self-declared coaches with different levels of ability and experience, different approaches, ideologies and allegiances fragmenting your efforts. I have seen more than one transformation initiative hoover up all the agile coaches they could find, only to eject them all some time later with little progress having been made.

Frustratingly this is one area where certification could help, by assuring a level of competence, consistency and experience, but that would require peer-appraised, practise-based certification and assessment, and there is no network of peers that could guarantee any degree of quality or consistency here, especially between the various competing scaling methods.

8. Consistent, invested, resilient leadership

From the top of the organisation down, the leadership culture will make or break an agile transformation. There are many adjectives that could describe good leadership. I have chosen these three as my key ingredients, although I’m sure others will have different and equally valid opinions.

Consistent leadership is in it for the long haul. Various sources tend to agree the average tenure of a CIO is around 4-5 years, which means a good proportion of them will be moving after 2-3 years. (There is a tendency for CIOs approaching retirement age to stick it out and skew the graph to the right.) I have seen otherwise successful transformations stalled and then abandoned after a change of senior leadership, especially when someone is brought in to “control costs”. They invariably interpret this as slashing departmental budgets rather than trying to figure out why so much effort produces so little value. Ironically they would gain much greater savings by following through on the transformation.

I had the pleasure of meeting Henk Kolk, former chief architect at ING Bank, in 2015 when he was talking about their agile transformation journey. When we met this had been going for some years and was still well underway. A recent McKinsey article shows that although some of the names have changed, the new incumbents have carried forward the same culture and commitment.

Invested leadership realises this is the future of the organisation, not a side project. In Theory of Constraints terms, the management team chooses to define business agility as the goal of the organisation and makes everything else subordinate to this. Senior execs can get distracted, often by external market or political factors beyond their control, so it is important they have a clear and vocal commitment. At one bank I was working with the CEO ran a kanban board with his management team. They used this to make work visible and to limit the amount of work in process and it was the focus of their daily standup. This said more about his commitment to business agility than any Town Hall address.

Resilient leadership is bigger than a charismatic chief exec. For leadership to be resilient you need leaders up and down the organisation, all committed to a common goal. I advocate two complementary leadership styles, namely servant-leader and leader-leader.

Servant-leader describes a dual role. You are both a servant to your team, ensuring autonomy, and anticipating and meeting their needs, and their leader, setting direction and holding them accountable. Many people professing servant-leadership forget this latter part and just see their role as “protecting” the team, but without direction you lose the alignment across teams. As Kent Beck said, “autonomy without accountability is just vacation.”

Leader-leader is a term coined by former US navy commander David Marquet in his excellent Turn the Ship Around, one of my favourite books on leadership. Each person in the organisation considers themselves the leader of their own area and “expresses intent rather than asking for permission.” In Marquet’s words, the idea is to “move authority to the information” by delegating autonomy, rather than “moving information to the authority” and having decisions bottlenecked at a poorly-informed, senior decision-maker.

Concluding thoughts

If you are already SWARMing you have my respect and admiration. I hope this article helps you identify gaps in your strategy, or at least reaffirms that you have the bases covered. As with any complex adaptive system, the factors I have outlined are all interrelated. Influence can buy you time and investment. Investment will raise the profile of your efforts and can give you more influence. Resilient leadership creates an environment that encourages practise, and so on.

If you are considering a journey towards business agility, be aware there are alternatives to wholesale adoption of scaling frameworks, with their recurring revenue certifications, closed community of self-professed experts, and methodologies that simultaneously promote inspecting and adapting whilst insisting on strict adherence to their branded processes, tools and methods. At best they can cover only a fraction of the landscape I describe above. The rest is down to you and the people you choose to travel with.

Methods like SAFe, LeSS, DAD and others are based on sound principles and may make a useful starting point, for example I have seen DAD used in a number of places to create a consistent initial vocabulary and terminology. But the best person to change your organisation is you, and the best way is however you figure.

Kotlin: Reified Type Parameters

Javalobby Syndicated Feed - Fri, 26-Jan-18 04:01

This post walks through a sample that demonstrates Kotlin's ability to cleverly reify generic type parameters.

So consider first a world where Kotlin does not support this feature. If we were using the Jackson library to convert JSON to a Map with String-based keys and Integer-based values, I would use code along these lines:

Categories: Java

Preposition Preference

Javalobby Syndicated Feed - Fri, 26-Jan-18 01:01
Photo taken at Grounds for Sculpture in Hamilton, NJ

A friend of mine at Rutgers University would always respond to the question "What's up?" with the consistent response: "A preposition." I fell into this trap far too many times.

Have you ever thought about how much we use prepositions in our Java APIs?

Categories: Java

CDI (Part 1): Factory With @Produces

Javalobby Syndicated Feed - Thu, 25-Jan-18 22:01

Hello!

This is the Part 1 of the CDI Series in Java that contains:

Categories: Java

Compile-Time Dependency Injection With Play

Javalobby Syndicated Feed - Thu, 25-Jan-18 10:01

The Play Framework provides a lot of features that make it incredibly easy to scale infrastructure. However, scaling a codebase is more difficult. As developers create new components and more complex relationships, the codebase can become unruly for all.

To help with this problem, one can use a dependency injection framework.

Categories: Java

Refining Redirect Semantics in the Servlet API [Snippet]

Javalobby Syndicated Feed - Thu, 25-Jan-18 04:01

This post is bikeshedding, but as bikeshedding goes, it’s very important to write about it.

In web applications, it’s necessary to prevent impatient users from POSTing the same data over and over again — for example, to avoid the pain of putting the same item into the basket multiple times because of a browser refresh.

Categories: Java

Rust for Java Devs: Compiling Code and Using Cargo

Javalobby Syndicated Feed - Thu, 25-Jan-18 01:01

After my last post seemed to be well-received, I am back with another Rust for Java Devs post. Today, we will look at compiling Rust code and using the basics of Cargo. For a developer, there isn’t much difference between how to compile Rust code compared to Java, but where they vary are their build tools. Rust comes built-in with Cargo to manage projects, whereas Java does not and relies on external build tools like Maven and Gradle. We can then use Cargo to build and run projects instead of directly compiling and executing the created .exe file.

So let's jump in.

Categories: Java

Adding Terms to Javadoc Search With Java 9

Javalobby Syndicated Feed - Wed, 24-Jan-18 22:01

There is a relatively old web page called "Proposed Javadoc Tags" that appears to have originally been written in conjunction with Javadoc 1.2 that lists "tags that Sun may implement in Javadoc someday." The tags in this list are @category, @example, @tutorial, @index, @exclude, @todo, @internal, @obsolete, and @threadsafety. One of these tags, @index, has moved from "Proposed Tags" to "Standard Tags" with its inclusion in Java 9. The Java 9 Javadoc tool documentation states that the @index tag is used to specify an indexed "search term or a phrase" that can be searched for in Java 9's new Javadoc Search feature.

The ability to add terms for searching in Javadoc generated documentation has been desired for some time as demonstrated by the existence of JDK-4034228 ("stddoclet: Add @index doc-comment tag for generating an index from common words"), JDK-4279638 ("Javadoc comments: Need ability to tag words for inclusion in the API index"), and JDK-4100717 ("Allow user-specified index entries"). JEP 225 ("Javadoc Search") was used to "add a search box to API documentation generated by the standard doclet that can be used to search for program elements and tagged words and phrases within the documentation."

Categories: Java

Spring Boot 2: Migrating From Dropwizard Metrics to Micrometer

Javalobby Syndicated Feed - Wed, 24-Jan-18 16:01

Spring Boot 2 is around the corner. One of the minor changes is the replacement of Dropwizard Metrics with Micrometer. The migration path is fairly straightforward, and Micrometer actually provides a cleaner API. With Metrics, you have to inject MetricRegistry wherever you need some metrics (see: Monitoring and measuring reactive application with Dropwizard Metrics). This has many drawbacks:

  • We are mixing business and technical dependencies in our components.
  • Therefore, I am sometimes reluctant to add new metrics because it requires me to inject MetricRegistry
  • Also, MetricRegistry must be stubbed in unit tests.

Micrometer's tagline is:

Categories: Java

Thread Slivers eBook at Amazon

Syndicate content