1. Initially, Microsoft envisioned the controls running in several places: perhaps the browser, a printer, or a zoo. But three and a half major versions in, we're still required to pass the same attribute with the same value for every control. Couldn't they drop the requirement and make it a default if they decided to add more valid values?
   
   
2. They wanted a constant reminder to novices that this code was running on the server. This way, people wouldn't ask why changes weren't occurring on the browser before posting forms to the server.
   
   
3. They wanted to remain consistent in having to tell the computer everything at least twice, à la Object obj = new Object();. However, in this case, it seems more like Object obj = new Object(type="Object");. I'm not sure why that is.

We might be standing around waiting for a pot of coffee to brew, and I would talk about how great it would be if we had some new flexibility in our code that didn't exist before. If I said it often enough or with enough conviction, even though I hadn't really put it on the team's TO-DO list, Rao might fill the gaps between "real work" looking at the feasibility of implementing one of these things. If it was easy (and cheap) to implement, he'd whip it out and check it in.

• You waste time and money if the functionality was not needed
• You increase complexity of the code base and make "it less resilient to change" if your code forces "the system down a particular architectural path."
• You could unintentionally make the application "less functional or desirable to the customer."

1. You've known the feature-requester long enough that you can pick up on things he's asking for, but hasn't yet asked for. I think you should be really close in this situation. How can you predict otherwise?
2. There is obviously something missing from the spec, and you have enough experience with similar systems to know it is missing. This might be something like "We need a login system." You can probably safely assume they'll need a way to log out as well, and perhaps even "I forgot my password" functionality.
   
   The logout functionality I'd almost always toss in (unless requested otherwise). However, even on the "forgot password" feature, I'd consider a couple of things. First, do I know the customer well enough that we've done another application for them and they wanted it? Second, is the budget big enough to where I know they won't be upset if I implement it?

1. Know the fundamentals
   It was no surprise that Neal led off with the DRY principle. Being one from the school of thought that "code reuse" meant "copy-and-pastable with few changes," I feel this is the most important principle to follow when coding.
   
   Neal uses it in the original sense: Refuse to repeat yourself not just in your code, but all throughout the system. To quote (If I remember correctly, The Pragmatic Programmer): "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." I can't think of anything that wouldn't be improved by following that advice.
   
   Continuous integration and version control are important fundamentals as well. Continuous integration means you know the code base at least compiles, and you can have it run your unit tests as well. The codebase is verified as always working (at least to the specs as you wrote them - you might have gotten them wrong, of course).
   
   Using version control means you don't have to be afraid of deleting that commented out code that you'll probably never use again but you keep around anyway "just in case." That keeps your code clean.
   
   Finally, Neal suggests we should use static analysis tools such as FindBugs and PMD that inspect our code, look for bad patterns, and suggest fixes and places to trim. Those two are for Java. Do you know of similar applications for other platforms? (Leave a comment please!)
   
   
2. Analyze code odors and remove them if they stink
   Inheritance is a smell. It doesn't always have to smell bad, but at least you should take the time to determine if what you really need is composition.
   
   Likewise, the existence of helper or utility classes often indicates a "poor design." As Neal notes, "if you've gotten the abstraction correct, why do you need 'helpers'?" Try to put them in "intelligent domain object[s]" instead.
   
   Static methods are an indication you are thinking procedurally, and they are "virtually impossible to test." Seeing the procedural mindset is easy, I think, but why are they hard to test?
   
   Finally, avoid singletons. I know Singleton is everyone's favorite design pattern because it's so easy to conceptualize, but as Neal mentions:
   • They're really just a poor excuse for global variables.
   • They violate SRP (link is to a PDF file) by mixing business logic with policing you from using too many
   • They make themselves hard to test
   • It's very hard to build a real singleton, as you have to ensure you are using a unified class loader.
   • More that I won't get into here...
   
   
3. Kill Sacred Cows
   Neal started off saying that "sacred cows make the tastiest hamburger" and told the story of the angry monkeys:
   
   A few monkeys were put in a room with a stepladder and a banana that could only be reached if the monkeys used the stepladder. However, when a monkey would climb upon the stepladder, all the monkeys would be doused with water. Then new monkeys were introduced and when they tried to use the stepladder, the other monkeys would get angry and beat him up. Eventually, the room contained none who had been doused with water, but the monkeys who had been beat up for using the stepladder were still refusing to allow new monkeys to get the banana.
   
   That is the light in which you may often view sacred cows in software development. In particular, Neal points out that
   • StickingToCamelCaseForSentenceLongTestNamesIsRidiculous so_it_is_ok_to_use_underscores in languages_that_standardized_on_camel_case for your test names.
   • Using getters and setters does not equate to encapsulation. One of my favorite sayings, and a reference to why they are evil is appropriate.
   • Avoidance of multiple returns in a method is antiquated because it comes from a time when we weren't using tiny, cohesive methods. I still like to avoid them, but will use them when it makes the code more readable.
   • Polluting interface names with "I", as in ISomeInterface should be avoided. It is contrary to what interfaces are about. Instead, you should decorate the concrete class name.
   
   
4. Your objects should be Good Citizens. Never let them exist in an invalid state.
   
   
5. Use Test Driven Development
   TDD provides "explicit dependency management" because you must think about dependencies as you code. It provides instant feedback and encourages you to implement the simplest thing that works.
   
   You can take it further by analyzing your dependencies with JDepend.
   
   And don't forget about YAGNI. Quoting Neal,

   Speculative development saves time if
   • You have nothing better to work on right now
   • You guarantee that it won't take longer to fix later

   Is that ever going to be true?
   
   
6. Use reflection when you can (and when it makes sense)
   It's not slow, and it can be extremely useful!
   
   
7. Colour Your World
   Nick Drew, a ThoughtWorker in the UK came up with a system of coloring the code you write by classifying it as to who will use the feature: only a specific business customer, only a particular market, many markets, or unchangeable infrastructure. Based on the color and amount of it, you can decide what value or cost your code has.
   
   It's a very interesting system, so I recommend seeing a more detailed overview in Neal's handout (PDF). You can find it on pages 21-22.
   
   
8. Use a DSL style of coding
   It lets you "[Build] better abstraction layers, using language instead of trees" while "utilizing" current building blocks. As he pointed out, "every complicated human endeavor has its own DSL. [If you can] make the code closer to the DSL of the business [then] it is better abstracted."
   
   I'll add that it's easier to spot logical errors as well.
   
   A funny quote from Neal: "It's almost as if in Java we're talking to a severely retarded person." Regarding that, he recommended looking at EasyMock as a good example of fluent interfaces, and that having setters return void in a waste. Instead, we should return this so that calls can be chained together (and if you are using fluent-interface type names, you could construct sentences in your DSL that way).
   
   Neal also noted a distinction between an API and DSL: API has an explicit context that must be repeated with each call. However, a DSL uses an implicit context.
   
   
9. SLAP tells us to keep all lines of code in a method at the same level of abstraction. Steve McConnell's Code Complete 2 tells us about this as well, but I don't recall if it had the clever acronym.
   
   
10. And finally, Think about Antiobjects.
    Quoting Neal, "Antiobjects are the inverse of what we perceive to be the computational objects." So instead of solving the really hard "foreground" problem, have a look at the "background" problem (the inverse) to see if it is easier to solve.
    
    As an example, he used PacMan: Rather than constructing a solution for the "shortest route around the maze," the game has a "notion of a PacMan 'scent'" for each tile." That way, the ghosts follow the strongest scent.

1. it always costs the same to ship each item: 5.00 (units of currency)
2. the company only needs to worry about one tax rate: 5%
3. the product costs 100 dollars each, and there is only one product.
4. customers can buy a variable quantity of this item (called "quantity" below)
5. there is a handling charge of 3.14 (units of currency) for each item.