I've been thinking about ORMs a lot lately and I've been wanting to write something about what I consider to be the DataMapper farce. I should be clear up front, I'm big Doctrine 2 fan. BIG. It's my ORM of choice every single time, or maybe it was... On principal I love Doctrine 2. My days as a Java developer made me grow fond of Hibernate and with time I've come to really appreciate object hydration via the DataMapper pattern alongside the Repository pattern. What I've appreciated most is the fact that I can write a model with no implicit dependencies, meaning my class "Foo" does not extend ActiveFoo or QueryFoo or BaseFoo or FooTable or GatewayFoo or FooPeer or MagicHotSauceFoo, it simply stands on it's own. In the case of Doctrine 2 my model usually gets some love from annotations or maybe Yaml if I'm looking to spice up my day.
Here's the thing I've been contemplating though and why I think this notion of portability is fundamentally a ruse (for now). In the PHP universe what other library provides a DataMapper implementation that would allow you to freely move from Doctrine 2? If I choose to write stand alone models I am either stuck doing some sort of hydration myself (all kinds of time consuming icky) or I am using Doctrine 2. So this idea that ActiveRecord locks you in and Doctrine 2 doesn't, is, well simply not true... Short of a viable alternative Doctrine 2 has a monopoly on the DataMapper pattern, making it as 'locked in' as using Propel or any other ActiveRecord-styled ORM.
Now don't get me wrong... This doesn't change the fact that I will likely continue to gravitate toward's Doctrine 2. I am going to hang tight and hope for some healthy competition that will allow me to write my models portable enough to swap in Doctrine 2 for odd days of the week and LibraryX for even days.
PHP has more frameworks then I have fingers and toes, and that diversity gives developers and architects alike a lot of choices when it comes to solving a problem. It can also be a total headache sifting through the options and making sense of what seems like chaos. As of late I've found myself using Symfony 2 to solve my problems and I am increasingly a fan of it's underlying architecture and the freedom it gives developers to work in slices or components of an application.
A fair amount of debate has hit the internet about the dependency model of certain Symfony 2 components. Some argue that component A with dependencies B and C is too much, or that because component A also requires dependencies D, E and F to run it's unit tests it's not a truly stand alone component and instead represent a "coupled" library or framework. I actually think there is a lot of merit in these assessments, but I don't believe it discounts Symfony 2 from being my MVC framework of choice. Nor do I think this somehow invalidates the fact that Symfony 2 stands distinctively different from the alternatives in the PHP community. Symfony 2 is a huge step forward from the land of tightly coupled frameworks (I'm looking at you Cake!). More importantly than the dependency model though, I think Symfony 2 presents an architecture of "Bundles" that simply doesn't get enough love in the current framework debates.
A bundle in Symfony 2 is nothing more then a stand alone unit of code. It may have dependencies, but it's stand alone in the sense that it represents a functional chunk of an application. A well designed bundle could theoretically be deployed as distinct unit from an application. Think about an application where you have an internal messaging system. Wouldn't it be nice to be able to peel that message system out of the main app and to develop it independently? When I say independently, I mean completely functioning on a web server without the rest of the application. This is bundle development at its finest.
Don't get me wrong, lots of bundles are not developed this way. I've seen applications where bundle divisions are completely arbitrary and others that had a nasty web of cross dependencies such that they should have just been in the same bundle. There is a happy place however, where bundle development represents a unique sliver of a larger application, and that place is why I'm so drawn to Symfony 2.
I've been working on a reporting bundle for a little while now. It's a simple concept, take an arbitrary query and translate it into a table. When I am developing it locally I actually have it bootstrapped into a vanilla Symfony Standard edition created by composer. When I am done with changes I deploy them into two different apps I've written that both use this bundle. The apps themselves have very little knowledge of the bundle, just enough to put some links into their respective menus, import a routing configuration and that's about it. What's most important though is that the reporting bundle itself has no knowledge of the two apps, such that I can develop it independently and deploy it to both without disrupting anything. The immediate benefits of this are rapid development and deployment, allowing for changes to trickle out to actual software faster.
This sort of development, application by slice or bundle, in a big team can optimize workflow by an order of magnitude. You can have a team iterating independently at a rapid pace without disrupting the other teams. In the end you have a forward moving application of independent and highly functional units. What's not to love about that?
Symfony 2's implementation is unique in my opinion because of things like extensions, compiler passes, bundle inheritance and the power of template inheritance. These aspects of Symfony 2 really empower unique slivers of code. When done right it's completely possible to develop a bundle that doesn't even need Symfony 2. Want to bootstrap a new framework and use your bundle? You can do that - it just requires some deliberate planning at the onset (aka inject, inject, inject!). Now some will read this an appeal to the awesomeness of Symfony’s dependency injection component and argue that’s really where the power of these slivers come into play. I disagree, I think it’s a piece of the pie - but fundamentally there is an underlying architecture and set of principals that lends itself to lose coupling of pieces of an application. What I wish though, is that this bundle mentality would materialize in some other frameworks!
** After writing this I was challenged with the notion of “plugins” or “modules” as they appear in some other frameworks. In my opinion most of the “things” that use this terminology lack the looseness of a Symfony bundle. A well written Symfony 2 bundle can in my opinion be bootstrapped without using Symfony. It requires writing Controllers that stand alone and are injected and it requires having a full grasp of your dependencies (no $this->createForm() please), but it can be done and the power of that independently deployable bundle is something that plugins and modules simply have not proven they can do just yet.
When I went to order my wife a new phone I couldn't get a straight answer as to whether or not the T-Mobile full-price version would be unlocked or not. The general consensus was that the device would ship with a T-Mobile SIM and be bound to T-Mobile's prepaid service at least for a couple of months. The whole thing was terribly confusing because you could order an iPhone 5C without a SIM in it at all, which is what I was hoping I could do with the 5S.
I pulled the trigger and ordered my wife an iPhone 5S from the Apple Store online, fully intending to cancel my largest bill, AT&T and move on with the latest and greatest. I value my freedom and at the core I'm cheap, so the long term savings and the short term monthly decrease was highly appealing to me. I had pegged my eyes on StraightTalk, the details of which are destined for another post, and figured we would complete that transition in a few months.
I ordered the phone and it arrived with a T-Mobile SIM. Now I've never done a prepaid plan before so I was a rookie at this in every sense of the word. I opened the box and I could not figure out how to get service started. There was nothing in the box explaining what to do and when I called T-Mobile they basically told me I had invested in a precious paper weight and needed to take it into a store. This was simply not the freedom that I coveted.
I happened to have a StraightTalk SIM laying around and after two T-Mobile customer support calls and three AppleCare calls I came to the determination that this device was most likely unlocked and I could kick T-Mobile to the can.
So here is the bottom line... If you are ordering an iPhone 5S, as best I can tell the device is in fact unlocked. It's worth nothing that I was not transferring a number and I did not have any previous accounts with T-Mobile. I was fed up and frustrated with the ridiculousness of their customer support and took a chance by sticking a StraightTalk SIM into the device - and it worked! My advice if you want to dramatically cut a bill and sport a new iPhone 5S is to not get hung up on T-Mobile when you order as it would appear these devices are free to roam about carriers as deemed fit by their owner.
Back in February my family moved from Pittsburgh to Southern Indiana. When we made the move we didn't actually know where we would end up. We put most of our worldly goods into storage and settled in with my in-laws for an extended stay while we shopped for a house. Whenever we've moved in the past we go through a process of purging the stuff we don't use. Trash bags get filled, car loads get taken to Good Will and we lighten the load for wherever it is we are moving to. This most recent move brought more purging then we've done in the past, by about an order of magnitude. Our house in Pittsburgh had an unfinished basement that was perfect for storage, so we quickly consumed every square inch of space with junk. When we moved most all of the basement's contents stayed in Pittsburgh one way or another.
When we finaly bought a house we settled for one without a basement or grandiose storage space. This caused us to yet again cut the waste from our lives. It's amazing how liberating it can be to become nimble by cutting the waste.
I tend to cycle through this same process with my office desk too. Every couple of months I empty my drawers and weed through everything, restoring only the necessities and essentially cutting the waste. On the other end of this process I can find things faster and I free up storage for new things far more important than the ones I get rid of.
Software development is no different. Sometimes you need to sell the house. Other times you just need to clean off the desk. In the end you need to cut the waste, trim the fat if you will. When I descend on a project one of the first questions I ask myself is, how can I remove as many lines of code as possible? It seems like a silly question, but the truth is that clarity comes through simplicity. Complex code often just needs to be gutted, whether through refactoring or rewriting. Understanding the initial problem is critical, but fundamentally cutting the waste creates a more nimble piece of software and this in turns translates to better results all around. Don't believe me? Pick a complex process and drop the gauntlet on it. Try simplifying it and set a goal to reduce it's footprint by 20%. I'm willing to bet the fruits of this labor will be profitable.
I recently read, "I will not do your tech interview." by Ike Ellis and it got me to thinking about the interviews I have been in, both as an interviewer and an interviewee.
The article resonated with me initially as I thought about an in-person panel interview I once sat through. The interview consisted mostly of brain teasers and had very little technical substance to it. For example, I was asked "If you had to determine how many cars were in the world how would do it?" Still to this day I think this is one of the dumbest questions I have ever been asked in an interview. My initial response was that I would google it. This only upset the interviewer because the whole purpose, in their opinion, of the question was to see how worked through problems. My appeal to them was that it was a question I would never encounter while working for them. The question was out of my wheel house as I knew very little about information measurement and market research gathering. The interview reached it's pinnacle when I was asked the infamous "Eight Balls" question that is most notable for its use by Goldman Sachs when conducting interviews. Needless to say I left that interview and called the recruiter to tell them I was no longer interested in the position. I have no idea if they would have offered it to me, but the bottom line was that they had devalued their company during the interview and I no longer had a desire or interest to work with them.
So Ellis article earlier noted then got me to thinking about the other side of the table and what I have done when I've been responsible for interviewing potential candidates. When I first started conducting interviews for development positions I compiled a list of questions that I felt assessed core technology to our product. They weren't product specific and quite frankly they were pretty simple. One question involved two pieces of paper with tabular data on them. The first question was about creating a relationship between table A and table B, with me ultimately looking for them to create a mapping table. The second question was to write a SQL query that joined the data together in a single result set. Answers were coded on a dry erase board, the least practical environment for any developer to write code.
I was once asked by a supervisor why I valued questions like the above and at first I replied, "Do you really want to work with someone that can't write a simple SQL query?" In hind sight turning the question back on him fundamentally missed the goal I was trying to accomplish. I was charged with finding the best talent available for our company and rather then defend the process on it's merits I surrendered to the question. The root of my problem came in evaluating or understanding what "best" meant for our company. I simply didn't know what we valued in developers and that lack of understanding created a flawed interview process.
I don't believe that "best" is the same in Company A as it is in Company B or that when Company C is hiring for position R it's the same as when they are hiring for position S. That needs to be said because it's too easy to simplify the solution to "best" as hiring the most knowledgable Senior Developer in the given talent pool.
Over time my questions proved to me that there aren't nearly as many senior developers around as management wanted to hire. So how do you fill gaps in technical leadership on a team? When you can't hire them, you make them (this assumes company buy-in on this philosophy). This in turn shifted my thought process from my quiz style assessment to a project style assessment. Perhaps I have my work with Project Foundry to thank for this revelation, but the bottom line is that I reached a point where I felt like I would gain better assessment data by looking at practical project based work instead of the results of a quiz.
My project based interview process involved a specification, poorly written like many of the ones I encountered at the time (this was deliberate), and some starting code to work from. My unrealized dream for this process was to couple it with a BitBucket repository so I could witness the progression of work through commit history. Eventually I also wanted to have deployment to OpenShfit for a working product because that's ultimately what developers do - they deploy the code they write. Here's the bottom line, with this process I hired three individuals. They all had different solutions to the problem and they were able to work on the problem without me hovering over them through the project. One guy was a Junior Developer who far exceeded the expectations set for him in the project and that turned out to be trend in his career thereafter. Another one of the other guys quickly moved up to a managerial role mentoring the younger developers on the team. His in person interview was memorable because of the awesome answers he gave when I asked him about his design decisions on the project. He knew his stuff and the project had established that, so his interview turned into a friendly chat about coding like you might find on a Friday at 4 when the cases of beer were being opened at the dev shop. The remaining developer remained a core code producer on the team up until the time I left that position. I considered all three of them victories for the new process.
I do believe that skill assessment for developers is necessary. I do disagree with the way we conduct those assessments. When I took the position I described earlier I had a timed online quiz that I needed to pass to be offered a job. I didn't and still don't see any value in that form of assessment. Those quizzes eliminate the ability for feedback loops and they dumb down computer science to multiple choice, which simply doesn't happen on real projects. My code questions involving a dry erase board for writing code also jeopardize a hiring managers ability to get good talent. Most developers simply don't code in front of other people and even fewer are confined by time in the way that we run these interviews. Our developers work on projects, either a spec or a ticket and that's where they are forced to be problem solvers and artisans. If we want to see how they will succeed in our companies we should give them realistic scenarios to demonstrate success.
Coming full circle we're back to the question of "brain teasers". What value do they hold? It sounds like even Google, once notorious for these, has given up on using them. I have to confess I don't usually excel at these challenges. Sometimes I downright freeze as I struggle to comprehend what it is my interviewer wants to see me do. It's like I'm trying to defuse a bomb that needs four gallons of water and all I have is a three gallon and a five gallon gas can to do it with (Die Hard 3). I wonder if It might be helpful if we look at other industries and take a page from their book. For example, how do Plumbers interview? It starts with verifying that they have a license which is then bound concrete hours doing specific work. Furthermore these positions have a license with it's own set of project-oriented assessment that is renewed and re-evaluated. What about nurses? They too are evaluated based upon on-the-ground experience doing actual nurse-work. There are verifications and accreditations based upon working experience that come into play. How do you decide to hire a contractor to work on your house? You look at his past work, the projects he's completed and you use the referrals of that work to come to a conclusion about whether or not he can be successful on your project. You don't ask a Plumber for an algorithm he'll never implement, you ask him to fix a toilet - which quite frankly just makes a whole lot more sense.
Things are getting easier for those interviewing developers. Thanks to tools like GitHub and BitBucket you can actually see things that developers are working on. You can also see a progression of their thought process in code commit history, a highly valuable tool for assessment in my opinion. After all, how much of what we do boils down to refactoring existing work? How better to see that skill then to run git log? Combine those tools with Cloud 9, OpenShift and even AWS and you have really easy ways to setup environments and projects that produce hearty evaluation data for potential candidates. Data that corresponds to actual projects and projects that mirror what they're actually going to be doing for you in their role. Lastly, a project-oriented interview process is more appealing to me as a developer too. Technology jobs are plenty but technology workers are limited. This means that as much as I need to sell myself as a product to you, you need to sell your company as a product to me. Your first exposure is through your interview process, so why not make it something that excites me as a developer to come and be a part of your team?