Skip to main content


Showing posts from March, 2015

Remote Meetings - Balancing the Act

Meetings are hard when some team members are remote and are physically based in the same location.It is easy for the remote user to feel second class in terms of the meeting. Remote workers can find it hard to add to the meeting without interrupting or getting left behind.One practice to balance the process of remote meeting is to ensure that if one or more parties are remote, all participants remote into meeting.BenefitsLevels playing field - everyone should have equal opportunity to contribute.Removes lag - everyone has the same experience of time/delay.Includes online benefits such as message logs, sharing of screen.Comfort of own desk/environment.This idea was taken from Stack Exchange's post detailing why they still believe in remote working.

Dependency Elimination Principle

This is the third, and final part of my series on abstractions. Part 1 - AbstractionsPart 2 - Reused Abstraction PrincipleI've wrote about what good dependencies are before, and the benefits if you can limit and remove them where possible.You can take this idea further though, by applying concepts from functional programming such as "depend on values rather than dependencies".A wise colleague started me down this path of passing values, rather than dependencies on collaborators after we repeatedly found ourselves depending on implementation details. This meant our high level domain logic was tightly coupled to low level implementation details.Brian Geihsler reminded me of this concept with an excellent demonstration of this in practice and has allowed me to put a name to this practice.Additionally J.B. Rainsberger's example is with a virtual clock, another common dependency we often need. In this case, ask for the time, not how you get the time. The example also hig…

Reused Abstraction Principle

This is the second part of my series on abstractions.Part 1 - AbstractionsPart 3 - Dependency Elimination PrincipleThe Reused Abstraction Principle is a simple in concept in practice, but oddly rarely followed in typical enterprise development. I myself have been incredibly guilty of this in the past.Most code bases have a 1:1 mapping of interfaces to implementations. Usually this is the sign of TDD or automated testing being applied badly. The majority of these interfaces are wrong. 1:1 mappings between interfaces and implementations is a code smell.Such situations are usually the result of extracting an interface from an implementation, rather than having the client drive behaviour.These interfaces are also often bad abstractions, known as "leaky abstractions". As I've discussed previously, these abstractions tend to offer nothing more than simple indirection.ExampleApply the "rule of three". If there is only ever one implementation, then you don't need …