About 10 years ago, Art+Logic christened its homebuilt project tracking and management system. At our Annual Conference that year, we voted on the name “Trantor.” I’m not a sci-fi nut like most of my colleagues but apparently the name comes from Isaac Asimov’s Foundation Series. Trantor was a planet which, in Asimov’s world, was at the center of the galaxy. Although I haven’t read the series, I do love that our company continues to celebrate and imbue in its culture all things geek.
We migrated all of our old project data over to Trantor and since then have been using the robust application as the backbone to our proprietary project management technique. It is a massive enterprise application, integrated with every division here at Art+Logic and, at this time, rightfully embodies its namesake. (more…)
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…)