#Ivory tower meaning vs blue collar software#

Patterns are an important part of the continuing evolution of software development. In such a case, high-tail it to Amazon or your local bookstore and pick up a copy of Head First Design Patterns. Besides, if you're a professional programmer working in any of the mainstream OO Programming languages, you should be worried if you're stumped by 'Decorator'. Once again, the onus is on the organization to ensure that there is a standard for pattern names and that the developers in the organization know that standard. The names of patterns give us a lexicon by which we can talk to each other about the arrangement and interaction of components, especially for those arrangements and interactions that we're likely to encounter again and again. I do agree that patterns are useful as a standard part of our design vocabulary: Just pay attention to the warning signs from your co-workers. If your architecture is screwed up, believe me, you don't need a book to find that out.

#Ivory tower meaning vs blue collar driver#

as a blue-collar worker, perhaps as an ambulance driver in Detroit or. A software architecture is good when- with a little education- it fits the developer's mental model of the way things should work and it makes them more productive. Many times I have yearned to venture out of the university's ivory tower into the.

Am I getting a lot of questions about this design? For things that I consider simple and straightforward?Ī software architecture isn't automatically good just because it came from a $45 book on Amazon.

#Ivory tower meaning vs blue collar code#

Do developers tend to write code that fits well with this design? Or do they keep 'getting it wrong' and forcing me to intervene?.Do I make a lot of excuses during the explanations? I wanted to do it this way, but.Do I have difficulty explaining my design to other developers? When I explain it, do I get the feeling that they are just nodding along to be polite, or do I get a palpable sense of engagement, that my ideas click with them?.Throughout the project, you should continually ask yourself: Gather feedback from the developers doing the work to determine if your designs are working. Forget the ten dollar acronyms and fancy diagrams. Never forget that you're a developer first and an architect second. It takes a good developer to make a good architect. They care only that the software works the way they expect it to.Īs an aspiring architect, I tend to agree. Your end users don't care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. From Web sites to database applications to games, it's all about what your code will do for the end user and not about how you did it. Deliver code that does what the end users of the code need or want. Define, design, build, test, deploy - that's what we do.

So let's quit treating it as if it's university research. It has more in common with the blue-collar 'build me a house' ethic than it does with ivory tower research. Software development is not an academic exercise. There's a provocative editorial on the 'Academication' of software development at DevX: