EDITOR’S NOTE: Many of our blog posts address “big picture” issues, such as ensuring a successful eCommerce launch, selecting an eCommerce solution, or integrating your CMS with an eCommerce solution. But it’s always fun to change things up and look at issues from new perspectives. There are lots of people here at ten24 who are responsible for making the magic happen every day. From time to time, we’re going to hand them the mic and ask them to talk about the issues that are near and dear to them. Everyone in this company has unique talents, strengths, and insights – we hope you’ll enjoy learning a little more about the topics that our team members are so passionate about.
Today’s post is based on a discussion we had with Ryan Marchand, Lead Developer/Slatwall, and Chris Kundrat, Application Developer/Slatwall backend.
When Marchand and Kundrat start working on a client’s integration, one of the first challenges they address isn’t about actual technology per se – it’s more about observing how that technology behaves in the client’s environment. They refer to it as cultural, or tribal, knowledge, and it’s important to get a handle on that knowledge in order for them to do their jobs effectively. As Marchand explains, “The client’s documentation might say that the systems act one way, but in reality those systems act completely differently. If you’re living with the systems day-in, day-out, as the client does, then you’re already aware of that – it’s part of your organization’s cultural knowledge. But if you’re an outsider who’s relying solely on the documentation that you’ve been given, you’d have no clue about that disparity.”
Before Marchand and Kundrat can roll up their sleeves and start programming, they must understand and acquire a client’s tribal knowledge so they know exactly what they’ll be dealing with as they prepare to integrate with that organization’s technology. And that leads us conveniently to the next hot-button item on their list.
Both men agree that in addition to mastering technology, they need to have what they refer to as some essential “soft skills” – and writing documentation is one of them. So what, exactly, does good documentation consist of? According to Marchand and Kundrat, you don’t want to write exactly the same thing that the code’s saying. Rather, documentation should be current and should provide a clear path for people to understand the technology they’ll be using. This requires striking a certain balance: If the documentation paints too broad a stroke, then nobody will be able to understand it. But if it’s too encyclopedic, people will never bother to read it. Says Kundrat, “The key is to write the documentation in such a way that you don’t need to be super tech-savvy to get through it.”
These could be considered soft skills as well, but they’re mission-critical when they’re tied to technology integration. The tools that Marchand and Kundrat use in their jobs are constantly migrating and changing. That means they (in addition to everyone else at ten24) have to stay on top of industry trends, monitor developments, and learn new programs, languages, and applications. There’s no such thing as a “typical day” for a developer, and that’s part of the reason they love what they do.
It would be easy – and wrong – to assume that developers hide themselves away in a back room somewhere working on technology. The reality is that they need to be in constant contact with their clients, especially with the client’s technical lead. Everything from making an initial proposal and reviewing documentation to coding, testing, and validating is based on timely and clear communication. Without it, everything else falls apart.
“We programmers recognize and look for coding patterns all day long,” Marchand says. “It’s what we do. If we can see one code pattern or shape in one place, we’ll expect to see the same thing in another area.” Recognizing convention and taking advantage of it makes it easier to code, scale, and maintain. For example, Marchand and Kundrat might observe that a pattern of code works just as well for products as it does for orders, so they’ll write something that works for both. This is especially important with a large integration that has many processes that stand on the shoulders of the processes underneath them. Of course, you can’t just change or eliminate code in one place without understanding how that will affect and impact the rest of the system. But if you can make a change that supports a number of functions, then you can expect those functions to behave in a similar way. Abstracting things and making them reusable makes everyone’s lives easier.
Both developers advise that when it comes to an integration, stability is a far bigger priority than performance is. That’s because the latest bells and whistles are no good if a system keeps crashing. Marchand and Kundrat are huge proponents of testing and validating what they build early on. They’ll perform domain/unit testing, which involves writing automation to test individual pieces of code. The benefits of this automated testing include not only better “code coverage” but it can also be completed faster and more frequently. But they’ll also perform end-to-end testing manually, (where many different operations are taking place simultaneously).
Identifying what they want to happen makes it easier for them to address the issue of bugs and error messages. As Kundrat notes, “There’s nothing worse than getting an ambiguous error message, especially the dreaded 500 Error. That’s the worst one of all. It doesn’t tell you anything helpful. If something breaks, you want a specific message about why it happened so you can refactor it with fewer bugs.”
Marchand and Kundrat freely admit that to the ears of non-developers, much of what they talk about can sound like a foreign language. “We’re basically like the archaeologists who worked on the Rosetta Stone,” Marchand jokes. “They tried to piece everything together so it made sense. We do the same kind of thing with technology integration, because we have to import and migrate information from a client’s legacy system and make it compatible with ten24’s system. The systems need to be able to talk to and understand each other – that’s at the core of what we do.”