random musings on software development and management

Taking responsibility

David Megginson recently included this in a post on LAMP stack stability:

And yes, my PHP web app is easy to maintain and extend, because I designed it to be that way (I can often implement, test and roll out new features in a matter of minutes, even when they require database schema changes) its the developer, not the programming language, that determines the quality and maintainability of an app. A lot of newbies use PHP, so there's a lot of bad PHP out there, but the same can be said for any language, even Ruby.

If an application needs to be malleable, it should be designed that way from the beginning. Most frameworks seem to be like pre-fabricated building foundations that include all the necessary structural support, plumbing, electrical, waste disposal, partnerships with various off-site storage facilities, and even landscaping. There's nothing wrong with trying to make things easier for developers by doing some of the work for them, but when the result is not what is needed, many frameworks offer little in the way of flexibility or malleability around substituting alternative components.

For many larger organizations, there is too much invested in the framework to consider going outside it's inherent confines. Doing so would "break something". It could be code, a testing philosophy, or maybe a policy that "development" shouldn't touch anything that lives outside the core application. Organization leadership and managers should empower developers take responsibility for thinking beyond the imposed confines to identify the best solution possible.

Some may see what David Megginson did as the actions of just another newbie PHP coder, but only if they knew nothing of his background.

tags: product management