About

I am a Software Craftsman.

I enjoy creating excellent code, and I enjoy helping and seeing others do the same.  I have managed software development teams for almost 30 years, and have a lot of experience in helping team members avoid the most common pitfalls.

Follow me on Twitter @agilepro

Intuition

What is the intuition of a software craftsman?  Good habits and good behaviors can be practiced and learned so they become second nature.  However, there are many aspects that are “counter-intuitive.”   That is to say that software has some unique qualities that make it distinctly different from development of physical products which we learn in other fields of endeavor.  Our assumptions from physical products sometimes do not apply to the non-physical software world.  I like to collect and archive good advice for software engineering, particularly those things that are non-intuitive, in order to avoid development problems before they happen.  With this, we can develop an intuition for excellent code.

Culture of Highly Effective Teams

A software development team is more about defining a culture than it is about defining source code.  As a programmer work, they  make assumptions about what others expect.  As a programmer reads code, they first follow assumptions about where they expect to find things and how the code will be structured.  There are thousands of different ways to organize things, but a team that sees things the same way will be many times more effective.  When I speak of culture, I mean specifically those things that have no right or wrong, but simply a “way things get done around here”.  The culture is a shared quality.  A well integrated software team works effectively because each person can anticipate the actions of others.  This can speed up work by a factor of 2 to as much as 10, and so, as you can imagine, developing an effective culture has a huge influence on the cost of the development effort.

About Me

I started programming when I was 8.  My father worked for the Los Alamos National Laboratory and needed some help.  The truth was he could have done it far faster himself, but wanted to give me some exposure to the latest ideas.  Luckily, the use of FORTRAN did not leave any permanent scars.

I studied Physics in college at UC San Diego because I wanted a grounding in classical science and had no idea I would be working in computer science all my life.   There was an amazing project there, called UCSD Pascal.  This was one of the very first microcomputer operating systems: the first on the Apple II computer, the first on the VAX, and one of three operating systems offered by IBM on their first IBM PC.  The school ran a self-paced computer course, and they needed tutors, so I learned enough about Pascal to get a job teaching it, so I could make a little spending money.  Then I joined a software startup making office productivity software running on microcomputers (a brand new thing at the time).

I have led a lot of programming teams through an uncountable number of software releases.  Since 1988 I have been following the Agile approach for developing software.  The methodology has come a long way since then, but there is still farther to go.

Goals

I hope this blog can be a forum for spreading good ideas about how to do software development correctly.  In any case I am using it as a way to preserve and distribute all of the various writings that I have made over the years.

Comments

None of this is 100% proven and there are many differences of opinion.  I welcome comment if you think I have not captured an idea correctly, or if you think of a better way.  It is only through dialog that any of us can hope to improve the practice.

Advertisement