Time To Change

First, let me set the stage:

I started my own consulting company in 1996. My focus was custom software development, but truth be told, I've never really had a focus. I've been all over the map. It's a wonder I'm still in business, but I keep learning. And here's what I think I've finally learned: I will do things the way I think is the best. It is TimeToChange. No more following the latest pop standard in the software development industry. Java is a fine product, but it is not the best - in my opinion, yours may vary - and I'm refocusing my consultancy to 100% Smalltalk/GemStone.

You probably think I'm committing market suicide, but hear me out.

Starting in 2001, the "warm body" (meaning: I sit at a client's site, take my lumps, and do what I'm told) consulting market turned really sour. I've muddled through the last year to roughly this date, but it hasn't been fun. And it isn't getting any better. The market for "warm body" consulting is about non-existent right now. For months I've obsessed about this, but then it started to dawn on me: This is a good thing!

I'm going to take all of the knowledge I've built up in various domains: Insurance rating, contact management, accounting, trading, asset management, delivery, real estate, medical, customer service, tractor repair and part specification and I'm going to build solutions for these markets. But, I'm going to build these my way, using the technologies and techniques that I find to be the best. For me, this means Smalltalk, GemStone, Windows 2000, SQL Server, and others. I'm going to support the leading Smalltalks: VisualWorks, VisualAge, Dolphin, and Smalltalk MT. But, primarily, I'm going to build applications to solve problems. IBM calls this being a Solution Provider; they're right.

When you walk into a company with a built solution, that is flexible and can meet any demand within its domain, you're in a completely different ball game. The company isn't going to care if the software was implemented in Rexx or Smalltalk, just that it does what they want. You've taken a large percentage of the risk and provided them with easy decisions to make. How many customers do you think ask IBM what language their COBOL compiler is implemented in? How about folks asking Microsoft why they decided to write portions of Visual Studio.NET in C#. Do you really think their customers make too much noise about this? Answer: no.

So, why should it be any different in the business software community? Why do we have to use bad tools, just because managers that don't understand them in the first place, say so? Because, right now, we're not taking the risk. We need to take on the majority of the risk. We need, as JoelSpolsky says, to eat our own "dog food". AlanCooper also articulates this in his views on InteractionDesign.

What this means to you is that you can do things the way you want. If you're a Smalltalker, then why aren't you implementing solutions in Smalltalk at least 95% of the time? Take the C3 project: Why couldn't Kent, Ron, and the others work together to build a kickass payroll system? They certainly have the domain exposure; they have the methodology to boot. I guarantee there's a company somewhere in the world that would buy that kind of experience - wrapped up in a complete and working payroll system. They'd more than break even.

We're giving Java all the strength it needs to dig in deeper. Why do this? I'm learning more and more it's all about your state of mind. Smalltalk isn't dead - it could be the hottest language on the other side of twelve months - folks just have to write some software and make it happen.

This is what I plan on doing.

(Just in case people still think I'm going goofy, think of this: There isn't, as of this writing, much different I could be doing. If this works, I'll be very happy. If it doesn't, at least I'll have some great software written in Smalltalk. I can always be a warm body somewhere. ;->) -- JeffPanici

Jeff, your plan is inspiring in a "damn the naysayers" kind of way, but has a weakness that introduces real risk to a project. Specifically, if you deliver a solution to a client built in Smalltalk or some other tool wielded only by a small minority of developers, where does that client find another Smalltalk developer in six months when they want to extend the system?

Your discussion reminds me of a marketing book that I read called CrossingTheChasm, by Geoffrey Moore. It's really a great book, with some interesting insights about how to bring technology products to market effectively. One of the things he highlights is that the value of a technology product is not defined by the product alone, but rather by something he calls the whole product, which consists of the product itself plus third party offerings and services built around that product. "Inferior" technology that is supported by vast legions of third party books, ancillary products, and thousands of skilled developers will surely be less risky than "superior" technology supported by a handful of tool vendors and understood by few developers.

Warning! Fallacy! Thousands of J2SE downloads from java.sun.com does not automatically mean "thousands of skilled developers"!!! If they don't know which patterns to apply, and how to write clear code, they'll still produce huge, steaming piles of unmaintainable, stinking crap. I've seen that several times over in the last couple of years. To me "skill" means awareness of the thought leadership on architecture and design patterns, refactoring and code quality, characteristics of good frameworks, etc., and I think it's significant that a lot of that thought leadership comes from veterans of the Smalltalk community. -- RandyStafford

Now, if you're just talking about building shrink-wrapped software using whatever tools you think are best, no arguments here. But custom development has a different value proposition, and we really ought to consider the whole product when choosing our tools in this arena. Despite its flaws, J2EE can be a less risky platform than, say, Gemstone/S, simply on the strength of the third-party market that developed around it.

(Slightly off topic, but it occurs to me that Smalltalk never took off in the mainstream developer community in part because it was revolutionary, rather than evolutionary. Its barrier to entry was just too high. You needed to learn a whole new syntax and a whole new development paradigm (OO). Real projects were being delivered in C, and when the mainstream began to see the value of OO in managing complexity, C++ was the path of least resistance. Recognizing this effect, Sun explicitly (and wisely) chose Java's syntax to mimic C++. C# tells a similar story.) I think pricing and inferior marketing had more to do with it - this has been hashed out in other places - see ReverseIndex links from WhoIsDougPollack. -- RS

-- ChrisDunworth

Chris, what I'm trying to do is merge the concept of "custom development" into a shrink-wrapped model. I hope that makes some sense.

First, to your point of "Who could provide support if it were written in Smalltalk?" (Because, of course, nobody uses Smalltalk ;->) We would. We'd never "lose control" of our software - it's ours. There is where the classic "custom development" model is different. In effect, I'm going to do the analysis of problem domains and build complete solutions. This includes the hardware, software, support, etc. If a particular customer needs 24/7 on-site support, they'll pay for a team of our developers to be on their site to serve this purpose. The customer will never see the guts of our system. We're providing a service-product. An analogy here is Windows or Unix: Many companies use these products without ever seeing the source code or knowing, exactly, how they're implemented.

Imagine if there were a "shrink-wrapped" version of a general "Clearing System". Banks, exchanges, and retailers could all use this kind of software. The key is proving to them that the software will provide the services we claim; not that we used the latest buzz-word compliant development language. -- JeffPanici

Jeff, perhaps (most likely) it's my thick skull that's getting in the way. From your description, it now sounds convincingly like you want to become a shrink-wrapped software vendor, straight up. Developing software to solve a domain-specific problem and later selling it to someone who needs it is what shrink-wrapped software is about, isn't it? That your company would also provide professional services to enhance the value of the software would be similar to many other software vendors, IBM being one example, Gemstone being another.

Invariably, even with the most complete packaged software, the customer will want to make it do something it wasn't designed to do -- integrate with a kooky legacy system, for instance. And this task requires skilled developers. If the skills required are in short supply (e.g. Smalltalk expertise), you're in the same conundrum as before. You might try to supply all the developers from your own company, but if business is good, you will be tapped out very quickly, and will have to turn to the marketplace....where tumbleweeds await.

I'm not trying to be a killjoy, I'm just having a hard time understanding the distinction between shrink-wrapped software and this blended approach. -- ChrisDunworth

The main difference, I think, is that we'd only provide the software to the number of customers we could support. If that happened to be one, then so be it. Now, I'd like it to be a greater number than one, but I'd settle for around five for a specific problem-domain. I want to run a profitable business that can grow, but I don't want to do this and sacrifice the techniques, technology, and ideologies that I think are best for developing software.

I agree that there are fewer Smalltalkers in the marketplace today than even two years ago. However, in my experience, even some of the most "kooky" enhancements I can imagine would only take one or perhaps two skilled Smalltalkers to pull off, especially with the proper frameworks and tools in place.

I do hear everything you're saying, and - as I said above - it does sound crazy/unlikely to succeed. But, I've built my business in a "one-step-at-a-time" mode all of this time, and I think by making this divergence I can "regrow" to where I want to be, and hopefully better satisfy my future customers. As a final note, I suppose one could use the ASP model as a loose analogy. However, the definition of this model is still, perhaps, too strict for what I'm trying to accomplish. -- JeffPanici

JeffPanici - I have been reading your posts here and am quite impressed with your insights. I feel a bit like there is an echo in the room. You have articulated some ideas that I have been struggling with for the last few years.

The recent focus on "community" in the programming world has seemed a little trite and insincere. With the Java(tm) chant ringing in my ears, and emerging from my fingertips daily, I can't help but think that there has got to be a better way. For some things anyway.

Nothing has changed in programming for a long time. It's all crap and it's all we have. Actually, it's better than that but I want more - more out of my profession and my personal investment in ideas and learning.

Working as a programmer is starting to feel very inefficient. I keep getting better but no matter how fast I run, the more our tools feel like quicksand. And I can't help feeling guilty because I know the world just can't afford for us to waste time messing about reinventing the wheel. Maybe I'm getting old and tired of the same notions repackaged as shinny bright new technology. BTW - I liked your analysis of EJB...

So what are we to do? Just stand here and take it on the chin until we get too frustrated and just walk away? No, that's just not me. I want to build something and I know it will take ten years or more to complete, but when it is done it will have changed the way we program - well, some things anyway.

You have touched on the key ingredient to building this larger-than-life something that I can't quite enumerate - yet. Own your code. Share it with people you trust and with their help build software that makes a difference. But don't make the mistake of giving it away. You need to see it through and the only way to do that is to make your efforts self-funding, contrary to the prevailing view.

Use your favorite tools as you know best. Soon the Java Geztapo will have blurred into history and the language arts will return. Best tool for the job and all that. Don't get me wrong, Java is great - well, for some things anyway.

I haven't figured out this wiki thing yet since I just ran across it five minutes ago. So I can't share my collection of links and ramblings but I'll be back!

-- KahunaMoore