Any time software and business come together, there is an inherent conflict between “get it done fast” and “do a good job”. This conflict often comes to a head when deadlines are missed, whether through unrealistic expectation or underestimation on the part of the developers.
The dilemma between quantity, speed and feature set isn’t going to go away any time soon. It’s an inherent dilemma in software. But there are approaches we can take to help solve it.
Note: I received a free review copy with the promise to write a review. However, this review is my own review and reflects my viewpoints alone.
What is wrong with this code sample?
Note: The recommendations in this post are intended for a very advanced audience. While the content applies broadly, creating and maintaining your own framework is not advised for everyone, unless you know exactly what you’re doing.
For many of us in the PHP community, our identities are as much tied into the framework we use as the language that powers our products. For better or worse, we often tie our careers to a particular platform, and we spend considerable energy on the community and culture of that platform and it’s supporting tools.
The modern web has largely settled on Model-View-Controller (MVC) as the paradigm of choice. Though it may ultimately be described by different names, these components are the core of what makes most object-oriented web applications work. And most people know that the model is the most important element of the application. But crafting good models can be extremely challenging. Many developers end up putting code all over the place, with the logic that belongs in the model scattered throughout the view and the controller layers.
What ultimately makes a good model? Where does each aspect of the model belong? And what is to be made of the other layers of the application? Let’s explore together.
I have a long-standing client who has a complex piece of software that I developed for them some time ago. From time to time they approach me and ask me to make improvements to the software, which I am almost always happy to perform. And like any good client they want an understanding of the cost before they move forward, largely to ensure that the cost-benefit analysis makes sense. And so, they ask for an estimate.
I’ve written on estimates in the past. I don’t like them, largely because they can tend to box you into a particular position that may or may not be correct.
Like many mentors, instilling best practices is an important part of what I do. And I encourage my mentees to follow best practices, including testing. For example, I encourage them that code isn’t done until it’s been properly tested, and that the higher the test coverage, the better the outcome overall.
Yet even as an advocate for testing best practices, I’ve steadily learned that “well-tested” or even “completely tested” doesn’t always mean “100% test coverage.” And while this might seem a paradox, it’s not.