Least knowledge

Before :

Let's say we have following Address class:

And we are using it in another class like Person:

And at the end, A client code that is going to use it in this way:

After:

Now Lets' change Person to add new methods to return first and second line of address:

So client can utilize new methods in this way:


What are the pros & cons for each solution (before and after) ?

The SOLID Principles, Explained with Motivational Posters

See more posters here  

Patterns of Effective Delivery - Dan North

Another excellent talk from Dan North.

Patterns of Effective Delivery - Dan North from Roots conference on Vimeo.

Velocity is Killing Agility!

• Velocity is increasingly being used as a productivity measure (not the capacity calibration measure that it was intended to be) that focuses too much attention on the volume of story points delivered.
• Focusing on volume detracts from the quality of the customer experience delivered and investing enough in the delivery engine (technical quality).
• Giving the product owner/manager complete priority control makes the problem worse—we have gone from customer focus to customer control that further skews the balance of investing in new features versus the delivery engine.
• Particularly for those parts of the business for which high responsiveness (a deployment cycle time of days or weeks) is critical, investment in the delivery engine is as critical as investing in new features.
• Management needs to allocate resources between features and engine work and then create a product ownership team consisting of the product owner and technical leader to do feature prioritization.
• Value (value points) and cycle time metrics will help balance the detrimental effects of velocity measures.

Read the full article : Velocity is Killing Agility!

InfoQ: Apache Harmony Finale

The Apache Harmony PMC initiated a vote earlier this week to begin the process of moving the codebase into the Apache Attic and disbanding the PMC. With 18 for and 2 against, the result will be that the Apache Harmony project will be wound up and placed in the Attic for posterity.

Apache Harmony was an open-source clean-room implementation of the JDK, released under the Apache license, but could never call itself Java compatible as Sun refused to honour the JSPA which would give them access to the Testing Compatibility Kit (TCK), a pre-requisite of which is needed before an implementation can call itself Java. Apache's open letter to Sun, published on April 10th 2007, asked for and failed to receive clarity on the subject.

continue here : InfoQ: Apache Harmony Finale

Being Agile with Lean Software Development

The “Lean” term has only been around in the business world since the 90s, but the underlying concept of lean production goes way back. While Henry Ford wasn’t the father of this approach (lean principles actually have Japanese roots), his strong focus on efficient use of resources is viewed as an important input in the development of this system. Automobile design and manufacture is definitely the industry most people associate with the lean philosophy since Toyota has made a point of marketing around this frugality and value-focused methodology for the last few decades.


read the full article here...

Spring: The art of using GRASP Patterns

When we search for design pattern articles, we found essentially documentation concerning “Gang of Four” patterns, they are very useful and contribute to well design application.

But when I discovered GRASP principles , I advice any one interested to improve his skills design to look at these principles, it gives a design fondamental rules.

In this article we will discover some GRASP principles used by Spring, and the advantages of using them.

read the full article...

From Months to Minutes

Another interesting presentation by Dan North.

Dan North reviews many Agile practices and concepts, mentioning what has really made the difference over the years and what has not, outlining what helps high performing teams to do their job.

Watch the presentation here at InfoQ if you interested in Agile topics.

On the road to being a better developer

Everyone wants to be good in what he’s doing – that’s human nature, that’s how we’re raised. The key is constant improvement without being disappointed by small failures and bumps on the way. In the last 10 years I’ve been working as a developer and I feel I’ve learnt a lot of valuable lessons – many of which can be applied to other areas of life and work. Let me share my lessons with you, dear reader.

Without specific order, a’la ad hoc:

Read the complete article here.

Whose domain is it anyway?

The brittleness of tests or specs is a recurring topic in BDD (or acceptance test-driven development, specification-by-example, or whatever you choose to call the thing where you write acceptance criteria, automate them and then make the application match). This is a tricky area, and there are probably as many styles of defining and grouping acceptance criteria as there are teams automating them.

The aspect I want to focus on in this article is domain language, because there’s a failure mode I encounter surprisingly often, which seems to have a common root cause.

Read the full story here

The perils of estimation

Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.

Agile teams I encounter are at best nervous about estimates and at worst simply evasive. “You don’t need estimates if you’re doing Agile,” they say. “It will be ready when it’s done. We’re constantly adding value so we don’t need to commit to a date.”


read the full story on Don North blog