I’ve had the pleasure of working with many internal development teams in my career in software development. For our company, working in partnership with internal development teams is, in fact, a common project type. Clients call on our particular services for any number of reasons but the most common are to a) increase development traction or b) supplement core internal skills with outside development expertise.
We’ve worked with internal teams comprised of a single developer as well as internal development teams for vast, multinational tech companies with internal departments that dwarf our entire company. (more…)
I may live to regret this analogy.
But let’s consider this a PSA for the purpose of maintaining your software application . . . perhaps co-sponsored by your local ASPCA or Animal Rescue.
I frequently find that clients think of their applications like a very heavy piece of furniture — one of those uber-plushy, leather recliners. You buy it, you stick it in the corner, and, there it sits, comfy and dependable, aging gracefully in place for years until a spouse puts a foot down and insists that it be updated for a newer model. The chair is dragged to the corner or sold at a yard sale or hauled to the transfer station. (more…)
I still run into a lot of companies that have the expectation that software development can be done on a fixed-price basis. They’re either still used to waterfall management style, or dealing with goods vendors, or, maybe a few are still running into software developers willing to work on a fixed-price basis.
On this blog, we’ve talked about the dangers inherent in fixed-price development services. How companies willing to offer an FPB will triple their hourly rate for change requests in order to make up the margin they already know exists between what they think the project will cost, and what it actually will end up costing. How every project, no matter how well planned out, rarely looks the same at the finish as it did at the start. How the number of unknowns at the start of a development project could fill a dump truck. What we haven’t talked much about is when it is reasonable to ask for, or expect, a fixed price. (more…)
In fact, when you go live, your software shouldn’t be “done.” If it is, you’ve done something wrong.
You see, in the history of software, there’s never been such a thing as a piece of software that launched without bugs. Think of your favorite, most used platforms. Gmail. Facebook. Salesforce. All are brimming with bugs. Every day a user writes into their contact forms about a bug they discovered, and while a lot of them are PEBKAC errors, a lot of them are legitimate bugs. And the ticket tracker logs them, someone triages them, and, eventually, most of them will be corrected.
But before that happens, some new feature will be added, or an existing feature will be modified (‘member when Facebook separated out the messages app from the FB mobile app?), and that will create a whole new series of bugs. (more…)
In the world of software consulting, it can be virtually impossible to determine what the fair market value for software development is. Nobody estimates work according to the same parameters: some firms have differing rates for differing services, some have offshore development services, some won’t provide a meaningful estimate at all (and for good reason). (more…)