Classic Graphics bet big on Drupal. Our largest customers get their orders on time because we have built systems for them based on Drupal. Even though we're up to 300 employees now, with layers of management, the non-technical management still is aware that we use Drupal for custom development in part because Bryan and I heavily evangelized Drupal within Classic.
Thinking ahead
One of the concerns we discuss at infrequent intervals is what Classic would do if Drupal ceased to exist or if Drupal is still the best choice for doing our custom development now and in the future for the types of accounts we're pursuing. Our considerations also have to include our guesses about how the community will adopt things like Symfony or what Drupal 9 might look like.
The recent acquisition of Classic by Imagine! Print Solutions raised the discussion again. The guys at Imagine! have largely bet their development platform on .NET. Should Classic now look to adopt .NET platforms, or vise versa. We pretty quickly concluded that was not likely, at least in the short term.
As a "printing company", the Classic and Imagine! sales teams obviously look for opportunities to put ink on paper, but companies who have failed to adopt computerized order management to match their customers' needs have been becoming extinct in the printing industry. A lot of big business still operate using spreadsheets that get emailed around between departments and edited by people instead of systems. The companies which are excelling in becoming service providers in addition to being a "print shop" can adapt their print manufacturing to a customized list of retail locations or to a particular grouping of kits.
Pain
You shouldn't hire a new accountant until your current accountant is unable to complete their work in a normal workday. You ask your accountant to work a couple extra late nights and start looking for another accountant. Wait until the pain has reached its peak, then relieve it. In the meantime, there's a waiting period to put a job posting out, wait for responses, interview people, do background checks, hire them, let them give 2 weeks notice at their current place, and then train them. From the date you decide to hire a new accountant, you may be putting extra stress on your existing team for another 5-6 months.
In my experience, nobody spends big money on custom software development to manage sophisticated data workflows until they're screaming in pain. That's probably the result of some prudent money management, but it draws parallels to adding to your accounting department. By the time a software development budget is approved and a business analyst has writtens some vague specifications, the customer is already impatient. They're living their peak of pain. They won't want to wait for prototyping, agile sprint reviews, automated testing, continuous integration platform builds, VM spin-ups. etc. The better you can streamline all the overhead of project ramp-up, the closer you are to just working on solving the customer's problems.
Insert: cinder block
In the situations where the project is already filled with hot, impatient people, the "when all you have is a hammer, everything looks like a nail" scenario applies. I think the best thing you can do in that case is use your hammer, but I prefer a slightly different view on the common analogy - using a cinder block; a hammer is much too elegant. A cinder block is a clumsy thing to carry around. If you've ever worked with cinder blocks for a long period of time, you'd also find they have fragile points that cause them to leave cinder block crumbs everywhere they go.
I also extend the analogy by introducing oak, the hard wood. Most construction projects for buildings take advantage of softer wood like pine. They're cheaper because soft wood trees grow quicker and are easy to work with. Even when you have the right tools, like a standard claw hammer and some hard-wood nails, driving a nail into oak is a tough task; you have to hit the nail harder, probably a few more times, but the nails are also much more likely to bend. Driving nails into oak simply requires more skill and patience than does pine.
Put it all together now. I think of development like driving a used nail into an oak board using a cinder block. Picture some skinny desk geek gently "tapping" a nail while awkwardly straddling a block. That's development. Even though he might know just where to put the nails, he's going to bend a lot of them.
Using the ideal tools
The problem with development is that developers can't just drive to Lowe's, buy a claw hammer or an air compressor with nail gun, and return to the job site. Professional development is the culmination of years of practice, trial-and-error, and research. For a developer to leave their cinder block behind, they essentially engage in a process of researching all devices that could be used for hitting a nail, types of screws and screw drivers, rivets, whether its appropriate to be using wood or if they should switch to aluminum, then narrow down to one with is most appropriate for a specified budget, go to meetings about how to hold the hammer in the right place, how to apply safety equipment, and on and on.
Since the customer always wants their solutions now, as cheaply as possible, when all the developer has is a cinder block, it's best that they use it. Drupal has been my cinder block since 2004 and I continue to use it because it's been able to solve most of the problems brought to me. It may not be always the most elegant, but I know how to hold the Drupal cinder block in just the right angle to bend the fewest nails. I've built up muscles for holding the Drupal block. Drupal has a lot of flexibility to change and hook in custom code and I've spent a lot of time already figuring out how to use Drupal in a way to minimize project startup overhead.
I think in Classic's case, since we've invested heavily in Drupal and staff that specializes in Drupal, it continues to be the bet for our development in the next 3-4 year window.
Preventing stale
One day sales is going to bring our development guys a project for which Drupal is clearly not appropriate and I would be foolish to use Drupal blinders and not prepare for such an eventuality. Merging with Imagine! makes another whole skill-set available for us to use for solving problems, but I encourage the developers at Classic to spend "community time." I've never really defined community time clearly, but if they were to test the boundaries, I think they'd find there really aren't many. I've even gone so far as to openly encourage non-Drupal after-hours private consulting. Mark is hosting a Meteor meetup this month, a javascript tool built on node.js. I've already tried to shove another developer into learning enough node.js to implement some new print automation on our internal sites, though we don't have any immediate customer-linked need for it. I even recently became certified as a Certified Secure Software Lifecycle Professional, having used some of Classic's business hours to study, because the studying alone made me think of how we could do development differently.
Concluding
Using your cinder block to hit all your nail problems isn't really all so bad because it's probably still the shortest, cheapest path to driving the nails. Keep researching and learning about other tools so you can occasionally hit the nails with a sledge hammer, the back of an ax head, or even a rare, standard claw hammer. PHP developers should probably be able to read some .NET code, try to take on some bug bounties for a node.js server, and write their own devops scripts in bash instead of trying to get a server admin to do it.
Post categories
Drupal