Becoming Software Craftsmen

I tend to agree with most of the ideas presented here in this essay. Where I disagree is when the author promotes certain types of frameworks and\or tools as a basis for "software craftsmanship".

I have been doing professional software development for over 40 years, now specializing in the Microsoft Development Environments. As a result, I received my most critical training during the mainframe era where software disciplines were at an all-time high even though we had our project failures as much then as now.

One of the things that is rarely ever mentioned when discussing software development talent is simple common-sense. It is not a framework, a tool, or even a paradigm followed that makes for a great software developer but instead the ability to craft code that is easily readable by the least experienced person who may have to deal with it while also processing efficiently.

Too many times I have seen the recent promotion of frameworks and paradigms as the answer to software quality when they have little to do with it. In fact many of the current frameworks are mere repetitions of what has already come and disappeared in the past. For example, the new trend in JavaScript is nothing more than a re-hash of “Classic ASP” with a different twist. It is nothing new since it is another version of an interpretive language.

TDD or Test Driven Development has been found to offer nothing over well designed traditional forms of testing.

Agile development is often used to pay lip-service by organizations that want to promote themselves as using modern development techniques but in reality are just using a newer form of “guerrilla programming” or “Just get it done!”.

ASP.NET MVC is just another paradigm designed to pander to the “purist crowd”. Not once has it ever been clinically demonstrated that this paradigm produces better results in terms of actual benefits to a business.

These are just some of the examples of what is occurring now in the mainstream, world of software development but at the same time the rate of project failure still stands at around 70% which has been a constant for over 35 years.

True software craftsmanship can only be attained from a developer truly has a love for the development of fine software no matter the language or tools used. And this can be only accomplished when the least amount of complexity is used to produce the results keeping the overall work simple and easy to understand. This is why I still use the basic tools I have always used to develop my projects. My work is very easy to understand and as easy to maintain once one understands the standard n-tiered pattern that is used across all my work.

On a final note, the suggestion that one should develop Android applications to learn software craftsmanship is somewhat far-fetched. For one there is only so much one can do with a mobile application. Second, there are so many mobile applications now in existence that this genre has quickly become saturated with such software. A better approach is to develop applications across several topologies for different interests that a developer may have. This means developing for the desktop, the web, and the mobile space. However, it is the desktop and the web where a new technician will learn the necessities of enterprise-level systems that in the midst of the current trends in mobile computing is a talent that is fast becoming lost on the newer generations of development professionals.

"TDD or Test Driven Development has been found to offer nothing over well designed traditional forms of testing."

That is not true. TDD has been found to eliminate more than 60% of bugs otherwise found by testing teams.

Agile development is "not just a new form of guerilla programming". It is a very effective software development methodology which, when applied correctly, lowers development cost over time. However, software craftsmen should be able to develop quality software both using Agile methodologies and otherwise traditional methodologies.

I disagree with your statement on TDD. I have spoken with a former long-term Silicon Valley Software Engineer who has used both types of testing methods in large projects. He stated that if the quality of both methodologies were equal than their was no advantage to one over the other. In fact, that is what I stated in my post. I did not state that TDD was of no value.

Agile Development has not shown to provide any reduction in the overall project failure rates. This has been demonstrated over the years via the analysis of project failure, which is still at approximately 70%. Second, Agile is just a form of the incremental or evolutionary development, which has been part of the recommended software engineering paradigms for many years. It is nothing new. However, most IT organizations do not practice true Agile techniques as they relate to actual software engineering paradigms. I stated this also in my post. As I have found on many assignments, Agile is just a trend used by many IT organizations to simply mask the useless method of "guerrilla programming".

Overwhelmingly, most corporations in the United States simply cannot develop quality software since they are too high-bound with bureaucracy and politics.

@Steve Naidamast I feel you may not fully understand the practice and motivation of doing TDD. If you're comparing TDD with 'traditional methods' of testing, then you're not seeing the full picture.

TDD does not usually eliminate other forms of testing. TDD is as much about design as it is about having unit-test coverage, allowing one to refactor with confidence. Some would even argue it is all about design, and the test coverage being a good side-effect. To write testable code, it most likely should have a simple-to-use API, have high-cohesion and low-coupling.

Red, green, refactor. It takes some practice to be good at it.

Yep I totally agree with Steve, but can't blame it, its in our nature, destroy and create :)

Michael:

I can understand what you are saying about TDD. However, the reality is that even if TDD does in fact provide a superior framework to developing quality software, few organizations actually implement the paradigm as it should.

Second, though I may be incorrect about this, the way I understand TDD is unit-test development first and then actual implementation. Such a techniques requires additional time that most companies are not willing to afford. However, as there may be design paradigms figured into this paradigm, TDD is generally compared to traditional testing methodologies, which do not require that additional time involved. Maybe I shoudl have been clearer in my statements on this but my intent was to state that between the two testing paradigms no one has been proven superior when both are of equal quality in their use.

I am a senior software engineer trained in the development of low-defect software. I know all of the required paradigms needed to do this and attempt to implement them in my own projects whenever I can. However, even in companies that touted the use of quality software engineering techniques, the best that happened was lip services to the concepts. And even where I have proven substantially the quality of such paradigms via the output I produced, project leaders still had no idea as to why they would even consider them.

I have been in the field over 40 years doing this work in a variety of environments and none of them, with the exception of certain project leaders, ever encouraged quality software development...

Hi Steve,
I agree to some extent with some of what you are saying here. I think every agilist would say that what makes Agile work is that it is a combination of techniques that were successful in the past. In other words, if things like evolutionary design and well factored code are good ideas, lets do them all the time. Agile has been very helpful in getting that word out, which to me is the biggest benefit of all.

While some corporations do indeed use agile as a way to mask guerrilla programming, the same guerrilla programming would exist in a more formalized approach. I contend that it is not up to the corporation to determine whether we as programmers write good code, but it is up to us. In other words, to abuse Shakespeare, "The fault, dear Brutus, lies not in the stars, but in ourselves."

If you write code for long enough and ask yourself what programs are made of, you can see four key concepts emerging [1]:
- actions
- types
- states
- relationships

You could argue there are a few more (say collections, events/messages or services) but that would not change my argument by much.

The core reason why we are "craftsmen" (and craftswomen) is simply because programming languages come from a different era, an era driven by lambda-calculus, an era where everything was either an action or a type.

We have to craft our code because we need to constantly (and inconsistently) encode state (an invoice is issued, received, paid, in default, reimbursed...) and relationships into types and actions. The programming languages that we are given are so insane that even SQL reifies a relationship behind the attribute of a type, or a type itself. There is no "relationship" concept in SQL (not to mention state), it's all the head of the developer. OO is by far the worst offender (by amount of code written) where action and types subsume state machines as a bunch of attributes and disjointed actions, and relationships as mere type composition mechanisms.

The sad part of this story is that States and Relationships are the structure of software, no type or action would make sense outside the frame(work) they provide. We are coding a bit like a residential architect would be build a house with beams and studs reified in paint and siding elements. Wouldn't work too well? hey?

That's why we have no choice other than being craftsmen. Perhaps it is time to change course [2], we tried that one for 50 years.

[1] Lambda-Calculus and Software Fevers
[2] Revisiting Barbara Liskov's assumptions

There is often a confusion in how people understand TDD. And how they see a non-TDD development.
It can be same level of unit testing, but tests created immediately after the "main" code. Or at unit tests are added some time later "as time permits". Or there might be no unit test coverage, only component/integration tests. Or just manual testing.

In each case the TDD vs non-TDD discussion is different.