Years ago, I worked for a company that had a strictly governed bug fixing process. The bugs to be fixed per release were specifically regimented, right down to the amount of hours available to fix each issue. Developers were expected to meet or beat their estimates, and failing to do so meant overtime (since the deadline was immutable). With effectively every working moment spoken for, there was never any free time for innovation, invention or creativity (at least on the schedule). Developers were effectively bug fixing or feature building machines, with no input into the process or product features.
Unfortunately, this seems to be an all too common trend in the development industry. Employers, who love the ability to measure things, disdain the fact that engineering is first and foremost a creative art, that cannot be effectively measured. They attempt to install artificial measures of productivity like tests written, lines of code added, bugs solved, and number of bugs reopened by the quality assurance team. Sadly, these measures all fail to effectively measure the effectiveness of development teams, because the developers themselves see immediately through the schemes, and learn quickly to game the system.
Friday, December 14th, 2012 @ 7:00 am |
Comment (3) |
Categories: Technology, Employment, Friday Inspirations
Tags: software development, development practices, engineering, engineering innovation, creativity, innovation, invention, development, engineer, leadership, Employment, boss, supervisor, employer, practices
The following is an excerpt from a draft version of Do This, Not That: Object Oriented Development. Sign up today to be the first to get a copy this week!
A few weeks ago, I was tasked with integrating a library that was designed by someone else. This library was intended to access APIs and return the data so that it could be used by my application. This seemed straightforward enough, except that the API I was working with had a few quirks, namely that it interpreted the query string directly, and so it was possible to have a query string similar to this:
Monday, December 10th, 2012 @ 6:00 am |
Comment (14) |
Categories: Best Practices, Object-Oriented Development, Software Development
Tags: private method, protected method, object oriented development, PHP, do this not that, development, library, library development, book, object, method
When I was a new PHP developer, I discovered that there’s a myriad of solutions, options, configurations and frameworks available. I thought, how does one sift through all the noise and get something done? How can anyone have a grasp of the best practices in PHP, and make sense out of all the options? Which extensions do we use, and how do we use them? What’s a best practice, anyway?
This is why I’ve decided to offer “Do This, Not That” for beginning and intermediate PHP developers looking to find a better grasp on precisely how to develop in PHP. This great series of highly focused e-books will offer tips, tricks and best practices focused on core areas of PHP development, including databases, security, filtering, regular expressions, configuration and more. Since it will be a series of tightly targeted solutions, developers will be able to pick all, some or just one of the offerings that solves their specific problem(s).
Monday, September 17th, 2012 @ 7:00 am |
Comments (0) |
Categories: Software Development, Best Practices, PHP 5
Tags: database, personal development, beginner, professional development, book, software, PHP, ebook, development, programming, improvement, Best Practices, intermediate, education, Learning, self improvement
In November of 2009, I wrote about why developers should write their own frameworks. I pointed out at the time that often developing a framework forces developers to make the kinds of architectural choices that frameworks require, which helps them better understand the architectural choices in the most popular frameworks.
I haven’t stopped believing in the power of doing as a learning tool. But in the past few months I’ve had an opportunity to move into more of an understanding of frameworks like Zend Framework, and I’ve come to another realization:
Monday, May 24th, 2010 @ 7:00 am |
Comment (8) |
Categories: Zend Framework, Technology, Object-Oriented Development, Open Source
Tags: Zend Framework, frameworks, NIH, development, Zend
Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the “sunk cost” of the time already spent.
This got me thinking about how often we consider the “sunk cost” in our decision-making process, especially when it comes to our software development.
Monday, May 10th, 2010 @ 7:00 am |
Comment (2) |
Categories: Opinion, Technology, General PHP
Tags: refactoring, fallacy, sunk cost, rewriting, development
PHP 5.3 has been out now for eight months, and in that time lots of projects have made decisions to begin developing against this version of PHP. Juozas Kaziukenas makes the argument that you shouldn’t be afraid of PHP 5.3 and he provides a number of excellent points to support his argument.
I don’t dispute that PHP 5.3 is faster, better, cleaner, and more feature-rich than previous versions. In fact, I’m thrilled to develop for myself on PHP 5.3 and even released a guide for installing it on Ubuntu because the Ubuntu package managers didn’t put it in for the last release.
Monday, March 8th, 2010 @ 1:00 am |
Comment (4) |
Categories: PHP 5, Open Source, Technology
Tags: development, Wordpress, php 5.3, Open Source, OSS
| « Older Entries |