Technique, Talent and Vision

Technique without talent is inefficient.

Some folks are just born with certain gifts and talents. They are smart in the right way to “just get it”. Whether it is music or leadership, or basketball, it doesn’t matter – some people are a “natural”. The rest of us have to learn the techniques and practice, practice, practice. While technique will get us pretty far, it will never catapult us into the same league as the natural talent. Our practice does not accomplish as much as the practice of the person with talent.

Continue Reading

The Hookup

My background for the last 27 years has been application systems development and integration. I have played every role from business analyst to developer to architect to project manager to team leader to director at one time or another. I know what gets application development teams motivated and excited about their job. I know what causes them to break down. I know what the distractions are and the inhibitors to effectiveness and efficiency. I also know the ROI on solving some of these problems.

Number 1 cheap answer to make software wonks happy and productive – The Hook Up.

They want the fastest workstation, the best software tools, the best technical environment and the most control over their own destiny that they can get.

When software developers are fighting against the toolset that they are using to build the software, and it’s inherent limitations, they are much less effective and efficient. Tools are cheap compared to devs – so we need to grow up and get over it.Continue Reading

Sufficient Tests

I’ll allow up front that I am not a huge advocate of TDD. Not because I think it is bad, its good. Not because I think it is hard, although it adds abstractions to the development process that are hard for some developers to grok. Not because I think it is a waste, because even though it adds time up front, it can save double on the back end. I am not a huge advocate of TDD, simply because it has the developers writing the tests.

Over years and years of software delivery experience, as a developer, as a tester, as a project manager, a business analyst, a manager I have observed one truism. Software developers cannot be trusted to understand the requirements deeply enough to test their own code. There are too many layers of abstraction in the way.

As Seymour Cray is reported to have said,

“The problem with programmers is, you never know what they are doing until it’s too late.”