How can you keep your corporate programmers on target? Try these suggestions from well-known PHP developer Luke Welling.
We all use PHP in our enterprises. It’s become the do-it-all language of choice for Web developers, from the smallest companies to the Fortune 500 and back again. However, PHP — which has been called “the one programming language that makes German look terse” — has problems with scalability. It is all too easy to write sloppy code that never-the-less works well enough to be rolled out.
Of course, as Luke Welling, Web Team Lead at Message Systems, a digital messaging management company and co-author of the “Bible” of commercial PHP/MySQL programming, PHP and MySQL Web Development, pointed out at an OSCON seminar in Portland, OR, that’s true of many corporate programming projects.
So what can you, as IT management, do about this? Well, for starters, Welling suggested that managers fight the attitude that sloppy programming is acceptable because IT can always “throw more and faster processors” at any performance problem. Sometimes, you can’t fix performance problems with hardware. You need to convince developers and their team leaders that writing to the minimum hardware requirements, rather than the maximum, is the smart thing to do.
You also need to fight the common programmer perception that all production code is temporary. This starts with the basics. Welling observed that many developers don’t even believe that the language or dialect they’re writing in is still going to be used in production systems in a few years. Wrong! According to Welling, the idea that “PHP code is going to hang around is not a crazy idea. Programming languages hang around for a very long time, as the COBOL programmers who were pulled out of retirement to deal with the Year 2000 bug found out.”
More specifically, you must convince programmers and their team leads that “No, the code you dash off today won’t be replaced properly next year. Unless the code causes real issues today there will never be time to replace it in the future.” Welling believes that “Inertia is powerful, platform changes are harder, rewrites are harder still, and people get stuck in their ways.” So encourage developers to get it right, or righter anyway, the first time.
That doesn’t mean that every development environment will be streamlined to make a developer’s life easy. When it comes to Web design, he said, “PHP is still not going to be a pretty language. It never has been and it never will be. Its strength and weakness has been its willingness to adopt features as appropriate.”
PHP is no longer a quick-and-dirty language, however. Or at least not solely. Welling said, “PHP has grown up with the Internet. It’s no longer a place for software tinkerers. People are no longer willing to accept failure since the Internet has become a utility service.” This is an important point to keep in mind. At one time, internal code tended to be inward facing. Now, with enterprise websites, mobile applications, cloud computing, and the programs once behind-the-firewall serving your customers, your in-house programs may be exposed to the external world. Programs that might have passed muster for your own users might not work well at all for the public.
Find a way to encourage developers to write code past what Welling calls the “80% level.” He explained, “Everyone likes writing new code and getting it to the 80% level [when] the features are pretty much done. That leaves the boring, but vital 20% of error handling and proper testing.” Few programmers like doing that last 20% of the work. Welling sarcastically noted, “Getting to 80% takes 100% of the time, and the remaining 20% take the other 100% of the time.” Without providing motivation, getting that last critical 20% done is often a real problem.
Your programming teams also need to be aware that “Today’s bad code often is the same as yesterday’s when spaghetti code was usually the problem,” said Welling. “Today, bad programmers write deeply nested hierarchy structures and Object Role Modeling (ORM) which can be slow and may be almost impossible to debug.”
The solution to such problems is that classic of design: KISS (Keep it simple, stupid). In addition, designers should avoid micro-optimizations. “They’re a waste of time. Your programmers should also avoid ‘cool’ design patterns, obscure performance tweaks, niche language features, new language features (no matter how much they may want to use the nifty new trick), and terseness in coding” that leaves follow-up programmers with no clue as to what the original designer had in mind.
Like any programming project, Web development needs managing and workflow. “It needs a Version Control System (VCS). It needs a review, build, testing, and release process. And it needs an easy way for developers to set up staging servers,” said Welling. Companies tend to cheap-out on the last matters. In his experience, a business may hire Web developers to create the code but won’t hire quality assurance (QA) specialists. “Someone other than the developers must do the testing,” he asserted, lest your public do the “testing” for you.
For all the problems your company may have with in-house development, remember that performance problems may not have anything to do with code quality, especially when it comes to the Web. Welling commented that “Most people don’t have traffic problems on the Web from their PHP code. The PHP processing time is generally a small part of the experience.” Instead, he said, slow Web load times are more likely to be due to massive third-party JavaScript libraries, large images, or the use of Adobe Flash.
Developers, managers, end-users, and customers want software that gets the job done, can deal with stress and failure, and can automatically recover when something does go wrong. If they can keep that “job one” clearly in mind as the goal and manage to “Write code that is readable and maintainable,” Welling said, Congratulations! Your enterprise will be well ahead of its rivals.
Related Information From Dell.com: Solutions and Services to Maximize IT Efficiency.
