Date Archives

April 2012

Flexibility and Configuration

I’ve run into numerous folks from both the business and technical sides of the world who want flexibility built into software. Developers and managers alike spew out statements like “We want to leave our options open”, “We’ll need to support that one day”, or my favorite “The business doesn’t know what they want”. As developers, we’re constantly faced with pressure to build things faster. Architects and technical gurus ingeniously figure that nothing is faster than making a simple configuration change. “Make it flexible. We don’t want to rewrite anything.” And with that we lay the first brick on the road to the inner-platform effect.

What we really want to do is minimize the cost of change.

This is why agile software practices were created. We want to be able to accommodate change, even late in the development process after significant progress. Some software developers take this far too literally, though. Accommodating change does not mean making every last detail configurable or worse yet, building massively over-architected systems in hopes of supporting yet-to-be-defined requirements.

Think about how long it takes to design and build all of those configuration points. Think about all of the permutations that need to be tested. At the end of the day, how many of those options will even be used? Remember, we’re making our systems and architectures flexible explicitly because we don’t know what we’ll use. By the time this infinitely flexible software is built something new will come along and we’ll realize in horror that we guessed wrong.

Flexibility means you design your software in a loosely coupled manner. Dependencies are injected instead of instantiated inline. You write classes that are 50 lines instead of 5000 lines. The SOLID principles become your best friend. Your software is simple, discoverable and, most importantly, testable. You can make changes swiftly and with confidence that the software is still fit for purpose. To me, this is true flexibility.

Why phpScheduleIt?

Every so often I’ll be asked why I work on phpScheduleIt. I’m not profiting from the project and the time I spend developing, supporting and on general housekeeping adds up quickly. The short answer is that the time I spend is fun and rewarding.

I’m a technologist at heart. I have been for many years. I crave learning and exploring new technologies. My day job gives me the opportunity to build some very cool software as part of an extremely talented team (more on this in a future post). The main drawback for writing software for someone else, though, is that freedom of design and technologies can be limited by deadlines and corporate decisions.

You’ll typically hear that open source developers are in it to “scratch an itch.” I’d completely agree. Building a calendaring application – with all the supporting functionality like permissions, administration and such – is a big job. There are plenty of technical challenges when working with dates and times and scheduling, especially across multiple timezones and cultures. These are completely different challenges than I face day-to-day, which makes them a lot of fun. And besides the code, I have an opportunity to envision and build a user interface to hide all of those technical challenges.

In addition to working with different technologies and design philosophies and so on, phpScheduleIt is an avenue for me to give back. I use a lot of open source tools and have benefited greatly over the years by looking at code. This application lets me take what I’ve learned and share it with others. My genuine hope is that phpScheduleIt is useful as an application to an organization or as a learning tool to an individual.

phpScheduleIt affords me freedoms I can’t get anywhere else. Don’t get me wrong… I get to work on plenty of emerging and fun technologies at my day job. But phpScheduleIt is a different type of fun.


It happened. I’ve finally jumped in to the world of blogging. My hope here is to teach, learn and have some fun.

I’m planning on sticking to technical topics, but I make no guarantees. It’s safe to expect a heavy dose of Agile software development, PHP & .NET code, design and tools, and plenty of phpScheduleIt.

You can also follow me on Twitter at @nickkorbel

Finally, please check out BrickHost. They’ve been an incredible partner of my phpScheduleIt project for many years now.