Scott Hanselman – It’s not what you read, it’s what you ignore

“The less you do, the more of it you can do.”

Entertaining talk about how to scale yourself. Some insights:

  • One email rule to rule them all: INBOX TO, INBOX CC, Bosses
  • Set three task you want to complete today / this week / this year (use timeboxing e. g. pomodoro technique)
  • Avoid conditioning your colleagues / bosses (e .g. don’t answer emails on the weekends / holidays)
  • Do one thing at a time (sound primitive, but that really works)
  • Don’t allow interruptions because of the high costs of context switching (better answer sth like this: “Ok boss, should I continue to make money for you or should I reboot your computer now?”)
  • Don’t use email as a chat client

Especially liked the quote of Timothy Ferriss: “Being busy is a form of laziness – lazy thinking and indiscriminate action.”

Greg Young – How to get productive in a project in 24h

Greg Young shows you some ways that can help you to quickly identify the painful parts of your software.

  • Data-mine your source control system
  • Find commit patterns that could be bad smells (e. g. islands where only a single developer is working on)
  • Get higher viewpoints of code
  • Get an overview of the dependencies (modules, package, classes, methods)
  • Don’t use gated check-ins based on software metrics
  • Code metrics are only a guidance for you
  • The interesting information lies in the deltas between changes (e. g. do you increase complexity or reduce it)
  • Use tools that signal “interesting problems” in your code directly in your IDE (again, for guidance)
  • Look for metrics that show you the “risk of a change”
  • Code metrics make you more productive because they can reduce your fears

Bottom-line: All code metrics are heuristics that give you a higher level of perspective of your source code. But they are no “words from god”, only a guidance.

Shoud I rewrite or reengineer a software system?

Shoud I rewrite OR reengineer a software system? Neither will work. Why? Watch Eric Evans – Strategic Design

The problems

Switching off the legacy system completely is a bad idea (unless it is really expensive to run)

  • While the new system is built, customers need new features in the old system -> leads to a race condition between the old and the new system
  • The complexity of the old system lies in the grown interconnection between all the parts of the system -> complexity of the old system is always underestimated

Reengineering a big legacy system is also a bad idea

  • If refactoring efforts are spread across the whole code base -> no big benefit will be seen -> those refactorings are drops in the ocean
  • If refactoring efforts are spent only on specific parts of the system, that seem to be important -> irresponsible hackers will destroy your redesigned areas later on
  • Expert (responsible) developers that are able to refactor the code base cannot produce new features -> Managers see no real outcome -> leads to less trust for the experts
  • Non-expert (inexperienced) developers (or hackers) implement the new features instead -> Managers see those benefits -> leads to more trust for hackers

The solution

Determine which parts of the system are both your unique selling point and complex (because if it wouldn’t be complex, your competitor could just copy your unique selling point). These parts are your core domain. Clean that parts up and “seal” them to avoid “attacks” from hackers (the irresponsible developers)

Try to outsource or buy all other parts of the system

Don’t try to create an enterprise model. There is no “one model” that rules them all!

The bottom-line

Know what is important for the business, and then work on your core domain.

Uncle Bob explains the Boundary Control Entity pattern in detail

Uncle Bob explains a great basic architecture pattern for designing understandable software systems. He shows in detail how the Boundary Control (he used “interactor” instead “control” to avoid confusing with the MVP pattern) Entity pattern works.

I think its in parts a little bit to inflexible an too much of a mantra, because you could get easily into mapping hell and many delegates. So use it only for what you really need in your application.

Further information: