When last we spoke, I discussed some of the pleasant discoveries that I had in my initial pair programming outings.  In this post, I'd like to share some of the pain points I experienced, my thoughts on mitigating them, and some additional thoughts on when pair programming might be more or less appropriate.

Waterfall model follows application development in phases with checkpoint and deliverable documents in each checkpoint. It advocates rigours project management, strategy and processes to track the status. The main drawback is that it require more than 80% project understanding before kick off the project which is impossible in major cases. Cause of volatile requirements and understanding business feels, 80% of software projects using this methodology fail to meet their objectives.

I’ve been a professional programmer now for over a decade, and during this time I’ve met a LOT of excellent programmers. Most of them are partially autodidactic and learned the business side of programming in school. But non of these guru’s/experts use their skills to teach the next generations.

New release of world-beating issue tracker focuses on faster, user-friendly interface.

Testing has a body of theory that helps its manageability and scalability. Many of the principles deserve to be borrowed into DevOps

The Economics of Software Quality, a book by Capers Jones and Olivier Bonsignour, provides solutions to quantify Software Quality which can help you to manage software development and maintenance. It contains software quality data that you can use to build a business case to improve the quality of your software and technical debt, understand what drives quality, and decide upon processes and techniques that can help to improve the quality performance of your organization.

“Fat models” cause maintenance issues in large apps. Only incrementally better than cluttering controllers with domain logic, they usually represent a failure to apply the Single Responsibility Principle. This talk explores patterns to smoothly deal with increasing intrinsic complexity (read: features!) of your application. Transform fat models into a coordinated set of small, encapsulated objects working together in a veritable symphony.

Using ASM to calculate test coverage in a new way. ASM is an all purpose Java bytecode manipulation and analysis framework.

A new maven plugin is available enabling git flow workflows in your maven builds

Jokes about “stupid developers” are still lurking in the corners, stories of “throwing things over the wall to development” continue to repeat themselves, and making fun of developer geekiness still prevails. Admittedly, I enjoyed these jokes as much as everyone else, but they always give me a bitter aftertaste; why is this barrier between testers and developers so hard to overcome?

Our behavior is always a reaction to the system around us. Let us take an example of an Agile team working on a project, and as we know its behavior would be determined by the stakeholders, leaders, enterprise culture around them.

Do you know what a Sprint Review is for, and how it differs from a Retrospective? In this article we look at what a Sprint Review is meant to be, why it is important, how it differs from a Retrospective, and what you can do to make sure one actually happens.

If you take anything away from this cautionary tale it is to constantly be on the look out for those that adhere to the status quo. It takes a certain combination of this quality with an opportunistic personality to cause this sort of organization-wide damage but it does happen.

Large-scale software and systems development involves a complex mix of people, teams, technologies, skills, architectures, and organizational structures that must all interact for projects to reach their goals. However, many organizations struggle to scale up agile approaches for their various programs, products, and services.

“The team is everything”, “The team owns its own planning” . yea right! As if my project manager and his PMO and marketing managers cares.. . Please join my first post about preplanning that tries to describe how my team tries to balance between the corporate demands for control and planning and the team autonomy as it should be in agile development .

When creating something of value, the first people we care about are those who will get value from the product we create. I call these Consumers. These are the users and those who are affected by the work of the users.

Service virtualization undeniably benefits the development process, but it can be both a blessing & a curse for developers. Learn how to minimize the burden on development to achieve maximum acceleration of delivery cycles.

DDD is not about saving effort "sometime in the future", it provides value by actually speeding up the development effort now. However, not by making us go faster but by helping us find a simpler solution.

The power of the placebo is based on our brain’s belief system. Because we believe the medication can work it does. I wonder if there is some of that placebo effect in our successes with agile? Could it be that all the results are really a matter of proper expectation? It often seems that the software industry is seeking one magic potion after another. We embrace the latest and greatest and hope it will cure our ills. Is agile just the latest elixir?

I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.