Magic Link Interview with Steve Blank

Steve Blank of S.G. Blank Consulting is no newcomer to eDeveloper™. His experience with, and advocacy of the platform, goes back more than 20 years to his introduction to Magic version 3.5 and it’s been his “tool of choice” ever since. But Steve is more than just a user; he’s an active contributor to the system’s capabilities. One example is the DDF Maker Wizard—a utility provided in eDeveloper V10—that lets developers enhance the eDeveloper studio by making their own utilities and wizards.

Magic Link: Tell us a little about your business.

Steve Blank: S.G. Blank Consulting only has one employee—me. I specialize in three different areas. First, I provide training for in-house developers on the latest aspects and features of Magic’s eDeveloper. Second, I speak at conferences and present seminars/classes on different aspects of eDeveloper. Third, I provide custom programming services to a handful of customers who, generally speaking, aren’t big enough to have their own in-house staffs, but who see the benefit of custom applications. It’s in this third area that I spend most of my time. I’ve been working with eDeveloper for about 20 years, since version 3.5, when it became my tool of choice, and I’ve been using it ever since.

ML: What types of training services are you called on to provide?

SB: Most of the companies for which I provide training are small to mid-size businesses with five or fewer developers. They are typically organizations that have developed their entire business system in Magic and, so, have a huge investment in it, and are looking for ways to improve performance or to solve other problems that have arisen as a result of their growth. So I’m usually not training people who are new to eDeveloper, but rather people in companies that have used the product for a long time and are looking for ways to make things better. The areas on which I tend to focus are multi-user concurrency, performance, database design, and data integrity.

ML: Do you typically provide training, then, for the same customers on a repeat basis?

SB: Yes. Often, I will get called in by a company that is experiencing a specific problem and, after helping them to resolve that problem, will then get called back to provide a wider scope of training. For example, a few years back, I received a call from a company in El Salvador that was experiencing increasingly serious locking and performance issues with their eDeveloper application. I went down and, after spending a couple days analyzing their application and database, showed them how to solve their problems and gave them some additional pointers on best practices. Each year since then, they’ve brought me back down for a week to train their development team on what’s new in eDeveloper, and to provide in-depth instruction on topics such as transaction processing and error recovery.

ML: You mentioned that you frequently speak at conferences. What types of things do you speak about?

SB: I tend to address many of the same topics that arise in my consulting and on which I often focus in my training, as well as to explore newer features in eDeveloper such as integrating ActiveX controls and COM objects. I really enjoy attending and presenting at conferences, for a couple of reasons: first, preparing for conferences gives me an excuse to experiment and create demo programs from which I learn something myself; and second, it’s a great way to network and to further my reputation in the business in a way that comes back to me. Plus, it’s just plain fun to meet and talk shop with people literally from all over the world.

ML: What are the kinds of issues that people have with eDeveloper that cause them to contact you?

SB: One of the strengths of eDeveloper is also one of its weaknesses: it’s really, really easy to write complex applications without a lot of formal training. Frankly, one can sit down and crank out some pretty amazing stuff without having any formal training in programming or database design because the tool abstracts the complexities to the point that the developer doesn’t really need to be aware of it. That’s one of its strengths because you can put applications together really quickly. But that also means that it’s very easy for bad habits to creep in. Take database design, for example. A Magic developer isn’t forced to be concerned about the table structures and such things that are underlying; one can just go in there and plunk things down. As a result, a lot of applications tend to have databases that aren’t at all normalized, which is OK when things are small with very few users. But as things grow and the database gets bigger and there are more concurrent users, problems can arise. That’s one example of when I might get called.

ML: What other types of issues do your clients have that you help with?

SB: A client might call up needing new reports or a change in functionality. One of the reasons I like eDeveloper so much is because it’s so much easier and faster to do not only new development, but also this kind of ongoing maintenance. One of the reasons to develop a custom application is so that one can constantly tweak it as one goes along, adding new features and functionality. With eDeveloper, that can happen a lot more quickly, which translates into lower cost (even when the customer is hiring someone like me to do it) than it can in something like Visual Basic. For example, my biggest customer in Massachusetts manufactures and distributes products for the optical industry. For lots of reasons, their software needs to evolve, practically constantly, and I make that happen. I develop a relationship with companies like that such that I’m really just an extension of their staff—almost an employee.

ML: There are some people who, like you, got started with Magic in the early days but then didn’t do much more with it. Why is that?

SB: First, Magic is a small company and suffers from a lack of brand awareness. Not enough people know Magic is out there, but it survives because of those of us who do know it are such zealous adopters that we just can’t see ourselves going anywhere else. More than that however, it often comes down to a political issue in favor of Microsoft. Whoever ever got fired for recommending Microsoft?

ML: Have you been able to observe companies like that?

SB: I knew one company that had developed its entire business system in eDeveloper and had run that way for 12 years, but then dropped it in favor of one of the major ERP vendors. They ended up shooting themselves in the foot. But once those decisions are made, people tend never to go back and revisit them or ask themselves if it turned out to be a good idea. They abandoned a significant investment in one system for another that ended up costing them many times more. But even though Magic has been around almost since the inception of the IBM PC and almost as long as Microsoft, people still ask, “Who’s Magic? Are they going to be around next year? Can we afford to take a chance with them, or should we go with Microsoft?” It’s a shame when a company turns its back on a significant legacy investment that was costing them much less money to maintain and, as a result, giving them a much better return on their investment.

ML: How can Magic go about showing those people what their prior investment in Magic could do for them now?

SB: I see a real opportunity now to speak to people who care about total cost of ownership. There are still people in this world who are willing to look at alternatives and to consider something different from the mainstream. Magic is doing a good job right now by releasing a product like eDeveloper Discovery, and by continuing to add new functionality.

ML: What advice do you have for Magic’s customers—old and new?

SB: Take a look at what Magic has done to improve the product over the years, such as addressing today’s increasing need to consume and serve web services, build and work with composite applications, and integrate with legacy applications and databases. If developers see how fast they can get the job done with eDeveloper and management sees how favorable the TCO is, they should agree that Magic is the answer.