A Constant Strive To Improve Productivity

To-Do List

Doing it wrong!!

I have an almost unhealthy infatuation with productivity and ways to improve it!

It begun many moons ago with a to-do list written on a scrap of paper. I started writing to-do lists for all kinds of things. What I planned to do at work each day became a to-do list. Things I planned to do around the house became a to-do list. As many others before me, I learned that having a to-do list itself doesn’t result in improved productivity.

Sure, I got things done and felt a sense of achievement, but I constantly felt frustrated by the number of incomplete lists. My infatuation with improving my personal productivity had begun.

Continue reading “A Constant Strive To Improve Productivity” »

It’s not ALWAYS the testers fault…

It's not Always the testers fault...

It's not 'ALWAYS' the testers fault...

…that your software doesn’t work!

I’m not saying it’s never the testers fault. What I am saying is this. It is not just the testers who contribute to the success or failure of your software.

  • How can this be the case?
  • Who contributes to the success or failure of your software?
  • What can be done to improve the chances that your software will be a success?

Product/Business owners….Lets discuss it!

This is the 2nd of 3 discussions around the roles and responsibilities of the Product/Business owner in the agile software development life-cycle. In this 2nd discussion I will look at the roles and responsibilities of the team members at the iteration level. In a previous discussions I looked at their roles and responsibilities at the project level (It’s not ALWAYS the developers fault…). In the final discussion I will look at their roles and responsibilities in the story delivery life-cycle.

Continue reading “It’s not ALWAYS the testers fault…” »

Improve Developer Quality Tip #1

Writing Computer Code

Writing Computer Code

This is the first in an ongoing series of tips for improving developer quality. Each tip will highlight development skills that I believe help improve code quality. Skills developers can learn via the resources linked to in the tip. Skills that once mastered will lead to better quality solutions.

#1 Transaction Models & Strategies

This first tip looks at transactions. Good developers can tell you that transactions need to have ACID (atomic, consistent, isolated and durable) properties. They will also be able to tell you that transactions help recover from failures and help to keep the data in a consistent state.

Continue reading “Improve Developer Quality Tip #1” »

It’s not ALWAYS the developers fault…

It is not 'ALWAYS' the developers fault.....

It is not 'ALWAYS' the developers fault.....

…that your software doesn’t work!

I’m not saying it’s never the developers fault. What I am saying is this. It is not just the developers who contribute to the success or failure of your software.

  • How can this be the case?
  • Who contributes to the success or failure of your software?
  • What can be done to improve the chances that your software will be a success?

Product/Business owners….Lets discuss it!

This is the 1st of 3 discussions around the roles and responsibilities of the Product/Business owner in the agile software development life-cycle. In this 1st discussion I will look at the roles and responsibilities of the team members at the project level. In subsequent discussions I will look at their roles and responsibilities in the iteration and the story delivery life-cycle.

Continue reading “It’s not ALWAYS the developers fault…” »

Ant, Ivy, JUnit 4.8.2 and OpenPojo – Part 1: Challenges

Just Do It!

Just Do It!

After announcing my plans to compare Ant, Maven and Gradle implementations in my previous post Ant, Maven, Gradle…or something else… almost 2 months ago, I have finally found some time to begin my little experiment.

The initial implementation involves the use of Ant with Ivy, to build and test a simple Java class. Dependencies including Ivy itself, JUnit 4.8.2 and OpenPojo should be obtained as part of the build itself. Anyone wishing to use the build should only require a working Java environment and Ant installed. It appeared to be simple enough in principle. It turns out to be a little more complicated in practice.

Continue reading “Ant, Ivy, JUnit 4.8.2 and OpenPojo – Part 1: Challenges” »

Ant, Maven, Gradle…or something else…

Arrested for not using a build tool!!

Arrested for not using a build tool!!

Do you use a build framework? Which build framework do you use? Is your build framework open-source, commercial or even custom? Ant, Maven and Gradle are three open-source build frameworks that I plan to use in a build experiment.

The experiment is intended to be the first of many set around the build process. Future planned experiments include the integration of these frameworks with repository managers, continuous build integration, static code analysis/error detection and reporting capabilities to determine technical debt.

Continue reading “Ant, Maven, Gradle…or something else…” »