In my heart of hearts I feel a software engineer, but I’m not ready to come out yet.
What triggered this somewhat dramatic thought was that on my current project I’m gently persuading the other developers to move, as the project keeps growing, from a Transaction Script approach to a Domain Model approach. However, I’m not using these terms, and I’m hesitant about forcing the point. My colleagues are for the most part experienced programmers that know how to get a program production-ready, but who don’t necessarily spend time reading about design patterns. They call themselves developers and are somewhat distrustful towards anyone preferring terms like analyst, designer or engineer. Frankly: I’m worried to not fit in, to come across as that new guy with his far-fetched book ideas.
What’s helping my coming out is that I’m reading Agile Principles, Patterns, and Practices in C#. In particular, I like an idea that I found in the appendix, a reprint of Jack W. Reeves’s article What Is Software Design?. The result of any designing effort, he says, is a document, based on which then the rather mechanical act of building the product can start. Applying that to software development, he says:
After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings.
As I said, I really like this idea, and it goes a long way in reconciling me with agile practices, what the rest of Martin’s book is about. You see, I’ve always felt instinctive distrust towards some aspects of agile programming, like the down-playing of documentation and upfront design in favor of producing working code fast. In fact, I felt that this way of working made software development feel less like a serious engineering discipline. After all, who would want their house built by an architect that says: “I’ve sketched out the main walls, the rest we’ll fill up as the brick-layers progress.”?
But if you start regarding anything upto and including the writing of source code as design, the perspective changes. It’s fine if there’s no definitive design before you start coding, because writing code is an integral part of the design effort. As long as you’re sure that the design is sound when the brick-layer/compiler starts his work, you’re fine.
I’m still somewhat suspicious about the whole concept of agile programming – in particular their view on social relations in developers teams seems somewhat utopian to me – but at least I feel like I’ll read the rest of the book with a more open mind.
