In High Output Management, Andrew Grove mentions the term lowest value stage quite a bit. It's a term from the manufacturing world: manufacturing adds value to things by taking raw materials and turning them into something else that can be sold. The lowest value stage is where you want to catch issues. Problem with a… Continue reading The Lowest Value Stage of Software: Getting Early Feedback
One thing I do pretty consistently when adding something to a web application is design the entity objects first, along with any associated value objects, without really thinking (or caring) about how those entities will be persisted or retrieved. For example, I recently had to design and build an audit log system for a project… Continue reading Design Data First
This article ist mostly about Symfony, but the advice here applies across frameworks. It's easier to define what's shouldn't be injected as a dependency: things global to the framework or the application being built. A form system is something global to the framework/application. Should the FormFactory be injected into every controller? How about templating? Should… Continue reading What Dependencies Should be Injected into a Controller?
Specifically inversion of control is about not making a choice in one place and forcing that choice to be made elsewhere. Take a library that talks to a database. Should that library make a choice on how to connect to the datatabase? If it does, that's a huge set of things to support and more… Continue reading Inversion of Control is About Choice
I used to have an interface for nearly everything when building applications and I've been pulling back on that position lately. Here I'll explain two cases where I've pulled back and written fewer interfaces. No implements Keywords Does Not Mean There Are No Interfaces This is important: every single object has an interface it presents… Continue reading Not Everything Needs an Interface
Something I've found myself doing more and more is writing lifecycle objects that add notification-like extension points to other objects. A good example is the MessageLifecycle interface and its implementations in PMG's queue library. Rather than pollute the queue consumers with events or other more generic things directly, the lifecycle provides and extension point into… Continue reading Lifecycle Objects as Extension Points
A coworker of mine took a new gig last week. One with increased responsibilities and a job title bump that put them into a more senior position as a company about the size of PMG or smaller. I gave him three pieces of advice. 1. Do Code Review, Not Style Review Worrying about coding style… Continue reading Three Pieces of Advice for New Senior Developers
With applications or libraries its easy to lose sight of the forest for the trees. It's easy to get lost in the details and forget the broad strokes of what the applicaiton or library or module is trying to accomplish. If that's true for the authors of said application or library, imagine how a user… Continue reading My Favorite Type of Documentation
The first type of interesting problem is the one everyone talks about: novel problems. New stuff, stuff that hasn't been tackled before -- either by the person doing it or the world as a whole. These are interesting for obvious reasons: it's fun to experiment -- to try new things and push both individual and… Continue reading The Two Types of Interesting Problems
A parameter object replaces one or more parameters to a method with a single object instance. A result object is a object created specifically for a return value from a method. Parameter Objects Changing a method to accept a parameter object is a common refactoring for grouping parameters that belong together. Unfortunately that's not the… Continue reading Parameter & Result Objects: More Than Grouping Values
Christopher Davis 