Questions About Software Craftsmanship Book

After I finished reading SoftwareCraftsmanship by PeteMcBreen (ISBN 0201733862 ) I came to the conclusion that I liked the book a lot, because it articulates many feelings and concerns I had about the state-of-art of software development, but was unable to express them. However, I have missed some reference to patterns. So

I wonder if the omission of patterns in the book was intentional?

I believe the writing about "best practices" in the book and the encouragement of sharing such practices at conferences is exactly what the pattern movement is about.

Personally, I think it was intentional to omit patterns. On page 124 onwards you will see that I argued against the idea of the OneBestWay? of ScientificManagement and suggest that BestPractices are just a holdover from those ideas. -- PeteMcBreen

I think your and my view of what good patterns give to readers are different. A honest pattern not only clearly sets the context of its applicability but also explains the limitations of its solution. So a (good) pattern description will never state that it is the one best practice to approach a problem, but it will show what worked well several times under given circumstances (forces) and where its resulting benefits as well as liabilities are. I know, not all popular pattern descriptions are always clear in these dimensions and some developers tend to take some patterns as the holy grail of object oriented design. -- PeterSommerlad

Wouldn't the PLoP series of conferences not be a perfect place for software craftswomen to share their experience and get the explanations improved to reach a broader audience?

Maybe, but personally I'm trying to encourage more variety in software development approaches rather than less. So I'm all for sharing, informally, but whenever a conference series gets involved, it can have the effect of shutting down alternatives. -- PeteMcBreen

I think craftsmen will improve or build tools they use. For software development I consider libraries and frameworks such tools. However, PeteMcBreen is somehow reluctant to PolyBloodyHardReuse. So I wonder what PeteMcBreen and others think about

Should Software craftsmen create and hone their own frameworks to create solutions and thus reuse software?

I support this idea to the extent that we can create long lived frameworks that evolve gracefully and are habitable (my thanks go out to RichardGabriel for that idea). Currently most frameworks and ReusableSoftware? cause a lot of grief for long lived applications. -- PeteMcBreen

can you give some examples from the "grief" side you experienced?

-- PeterSommerlad

Examples of possible grief

Frameworks that do not support all of the platforms they claim to - I ran into this in the OS/2 world about 6 years ago, cross platform GUIs didn't really support OS/2, but claimed to - with hindsight it might have been better to create an OS/2 specific front end.
Vendors that go under or drop support for your framework - Glalaxy comes to mind here
Frameworks that change drastically between versions - Early to later MFC, AWT changing into Swing

Those should be enough to get the conversation started. -- PeteMcBreen

And the alternative to using MFC for GUIs on Windows or AWT for GUIs in Java would have been?...

In Java, create a Canvas rather than a Panel; build your own lightweight GUI elements using drawing primitives. You probably didn't want 99.9% of what Button was trying to do anyway :-).

I'm assuming you are joking of course. I mean part of the great thing about these frameworks is that we don't all have to, say, build our own grid control. Why reinvent the wheel when you don't have to? If you need something that isn't in the library build it, but not using what is there makes no sense from a practical standpoint. I won't be buying this book if these are things it suggests and hope others don't.

You change your mind later, and that's good. That said, please refrain from telling me not to buy something. After all, you were wrong, and I can make my own choices.

All I need is some of my fellow engineers rebelling and saying they are going to write their own GUI toolkit before they begin to build their next business app. If your code is structured well and the presentation layer does not contain any business logic, then swapping up to newer versions of GUI components is just not that hard... and it is a lot less effort/cost than maintaining your own GUI toolkit.

I doubt that he is joking. I've written grid from scratch three times now. Each time it took two days to look up all the graphic and event stuff needed to make a good one in the technology of the moment. I've also used off the shelf grids maybe ten times. Each time I thought it was going to be easy but it turned out to be hard. It gets hard because I always get stuck with some sort of brain damage that I can't work around so I end up using my second or third choice implementation. By then I have developed a grid implementation isolation layer that is probably nearly as complicated as my hand crafted grid. Elapsed time: one week. One time I came across an off the shelf grid that was simple and powerful. It came from a small company of experienced developers that were making the libraries that they would want to use. Unfortunately they were driven out of that business with the release of swing. -- WardCunningham

You know what? After thinking about these ideas some more, I do, in fact, agree. If one is going to write software that is going to last 10 years, one must be in control of everything because there is no vendor out there that is not going to commit "brain damage" at some point! The questions now for me are: How are we ever to convince companies to think long term when building software? Is there a time and place for disposable software, or must we always think long term?

The book raises the issue that frameworks and ReusableSoftware? need to be carefully evaluated against the potential lifetime of the application. If your organization needs an application that can be maintained and evolve for at least 10 years, then you need to be careful about the software and tools that you use. Sure you can carefully encapsulate, wrap, compartmentalize or otherwise manage the dependencies, but my key point was that long lived applications need long lived tools. Few frameworks and little ReusableSoftware? seem to be developed with this in mind. Hence as developers we experience grief when the software we rely upon changes in incompatible ways.

So no I was not suggesting building custom GUI toolkits, more that we should choose longer lived software where possible and pressure vendors to think about longevity. Also as developers of long lived applications we could also think about living slightly behind the bleeding edge and plan for the necessity of dealing with discontinuities in versions as they arise. -- PeteMcBreen

Now I better understand what PeteMcBreen means by grief. When I think of frameworks I was not thinking about third-party stuff, but evolving your own framework from applications you created in a similar domain (like we did with Web applications). The bad thing in marketing development by using your own (proprietary) tools is that today customers believe you need to be using the major buzzwords (Java, EJB, multi-tier, ...) to create an application, even when doing so is completely ridiculous to a craftsman. So, how can we convince customers that YAGNI and DTSTTCPW is better for them, than bleeding edge, high-profile, hype stuff? -- PeterSommerlad

(YAGNI = You Ain't Gonna Need It; DTSTTCPW = Do The Simplest Thing That Can Possibly Work)

I too am grateful for the book - thanks, Pete, for giving voice to the community of us who feel this way about our profession.

I'd like to focus on a question that I noted in the margin of my copy on page 29. The second paragraph on that page says "... the craft ... nearly died out due to competition from mass-produced items. ... In software development, the same trends led to the prediction that programmers would soon be obsolete as software factories took over their duties. ... software developers never really became comfortable with the underlying premise"

The question is, what does this say about ComponentBasedDevelopment and EnterpriseJavaBeans? EJB is based on a set of EjbArchitectureRoles (bean provider, application assembler, etc.) and, as I noted on that page, I don't think those roles reflect how systems are really built. I am uncomfortable with that premise.

Would anyone agree that EJB is (wrongly) predicated on the "industrial model" of software development? Why is it that the long-predicted "component marketplace" has never materialized?

-- RandyStafford

The closest things to this "component marketplace" I have seen are Perl's CPAN, PHP's PEAR, Ruby's RAA, etc. where the components are free for the downloading. Since these "marketplaces" seem to work quite well, why would I want to deal with EJB's apparently more complicated and expensive model?