Tony Lukasavage: “Programmers: Why do we do it?”:

…those who truly love programming see it as an art form. Its not just a technical pursuit, but one that allows the leveraging of one’s unique talent and views. You bring a form of personal expression into your work. You invest yourself physically and mentally in what you do. You suffer and toil, using code as your medium, just as other artists craft with paint or stone. You have a personal association and pride with its creation. The code and its results represent you.

Chad Fowler: “Dead-End Jobs: Are You Suffering From Stockholm Syndrome?” (reddit conversation):

According to the Bureau of Labor statistics, American adults spend by far more time working than any other activity. That’s a lot of your waking time being trapped in a routine. In a Stockholm Syndrome situation, the captor chips away at the self-esteem of the captive. So for most of our waking hours, those of us trapped in dead end jobs like these are exposed to environments which systematically destroy our self-confidence. Not only that, a persistent fear and feeling of failure makes it harder to actually explore the options for leaving the bad situation. The instinctive self-preservation reaction in this kind of situation is to work harder to try to avoid the perceived threat coming to fruition.

David Veksler: “Some lesser-known truths about programming” (lots here, but I want to quote the following in particular since when I use the words ‘conceptual integrity’ I get blank stares too often!):

Software obeys the laws of entropy, like everything else. Continuous change leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but programmers who fail to take conceptual integrity into consideration create software that rots so so fast that it becomes worthless before it is even completed. Entropic failure of conceptual integrity is probably the most common reason for software project failure. (The second most common reason is delivering something other than what the customer wanted.) Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are killed.

Martin Fowler: “Is Design Dead?”:

…I think there is a role for a broad starting point architecture. Such things as stating early on how to layer the application, how you’ll interact with the database (if you need one), what approach to use to handle the web server.

Essentially I think many of these areas are patterns that we’ve learned over the years. As your knowledge of patterns grows, you should have a reasonable first take at how to use them. However the key difference is that these early architectural decisions aren’t expected to be set in stone, or rather the team knows that they may err in their early decisions, and should have the courage to fix them. Others have told the story of one project that, close to deployment, decided it didn’t need EJB anymore and removed it from their system. It was a sizeable refactoring, it was done late, but the enabling practices made it not just possible, but worthwhile.

How would this have worked the other way round. If you decided not to use EJB, would it be harder to add it later? Should you thus never start with EJB until you have tried things without and found it lacking? That’s a question that involves many factors. Certainly working without a complex component increases simplicity and makes things go faster. However sometimes it’s easier to rip out something like that than it is to put it in.

So my advice is to begin by assessing what the likely architecture is. If you see a large amount of data with multiple users, go ahead and use a database from day 1. If you see complex business logic, put in a domain model. However in deference to the gods of YAGNI, when in doubt err on the side of simplicity. Also be ready to simplify your architecture as soon as you see that part of the architecture isn’t adding anything.

…In order to work, evolutionary design needs a force that drives it to converge. This force can only come from people – somebody on the team has to have the determination to ensure that the design quality stays high.

This will does not have to come from everyone (although it’s nice if it does), usually just one or two people on the team take on the responsibility of keeping the design whole. This is one of the tasks that usually falls under the term ‘architect’.

This responsibility means keeping a constant eye on the code base, looking to see if any areas of it are getting messy, and then taking rapid action to correct the problem before it gets out of control. The keeper of the design doesn’t have to be the one who fixes it – but they do have to ensure that it gets fixed by somebody.

A lack of will to design seems to be a major reason why evolutionary design can fail. Even if people are familiar with the things I’ve talked about in this article, without that will design won’t take place.

…So is Design Dead? Not by any means, but the nature of design has changed.

Joel Spolsky: “The Guerrilla Guide to Interviewing (version 3.0)”

Joel Spolsky: “The Joel Test: 12 Steps to Better Code”

Joshua Thijssen: “The software managers “joel test””

Lucas Ward: “Maven and Continuous Delivery”

Uncle Bob: “Incremental Architecture”

Steve Yegge: Good Agile, Bad Agile

InfoQ Presentation: Martin Fowler and Rebecca Parsons: “Agilists and Architects: Allies not Adversaries Presentation”

Martin Fowler: Domain Specific Language

InfoQ Presentation: Martin Fowler: “Introduction to Domain Specific Languages”

Dave Thomas: “The ‘Language’ in Domain-Specific Language Doesn’t Mean English (or French, or Japanese, or …)”

defmacro.org: “The Nature of Lisp”

Jun Auza: “Top 50 Programming Quotes of All Time”

Antipatter: “How to Manage A Tech Career”