Lessons Learned – Custom ERP in Smalltalk | Hacker News Reader

Lessons Learned – Custom ERP in Smalltalk

smalltalk-bob.blogspot.com

29 pointsmpweiher17 comments

Last I looked Visual Works smalltalk had weird license schemes that involved perpetual royalties [1]. When I used to work in business/enterprise software (no longer, thank FSM) this was an instant deal killer, especially for small businesses.

Any information on how this was dealt with on this project would be greatly appreciated.

[1] http://www.cincomsmalltalk.com/main/products/pricing/

afaict this custom ERP would fall into "Companies that plan to use Cincom Smalltalk for developing applications for use within their own corporation" -- so your question does not apply to this case.

Working on an ERP startup^, this was a very interesting read for me. Our situation is a little different, because our goal is a customizable platform rather than a single instance built for a single company.

Some points that resonated with me:

Pay your technical debt early: Cleaning up after yourself as soon as it becomes apparent you've made a mess is huge. The most painful parts of our application to use and to modify were built the wrong way (in hindsight) and haven't been overhauled yet. The amount of additional work that has gone into building and maintaining those parts over what would have been necessary is massive. Of course, you can't always know how to build it right until you build it wrong. Take the (tech debt) loan, but make sure you've budgeted for paying it back quickly so you don't keep paying the interest forever.

Show progress and Have clear metrics: These have been very important for us. We started (some time ago) using milestones in our implementations to keep client expectations in line with reality, and to keep ourselves on track and smooth out the effort/time curve. This is probably project management 101, but it seriously helps keep clients happy and reduces stressful last-minute work.

On the other hand, I have to question the necessity of a custom ERP and the cost and effort put into it. "Total effort was about 16 to 18 person years (our team size varied from 3 to 5 over 3.5 years)." It seems to me that a lot of wheels may have been reinvented. In our experience, many companies think they have totally unique processes and data to track, when they're really doing just about the same stuff as their competitors. There can definitely be advantages to having a custom, integrated system, but on the other hand, a more flexible and customizable system can be deployed much faster and cheaper. Not SAP, but there are other options.

Bob: I'm not sure what you can share, but what are the key benefits the company expects to get out of a custom ERP? How big is the company? What is the breadth of the software, here--does it include e.g. accounting, or mostly industry-specific data collection?

On a more technical note, can you expound a little on how Smalltalk factored into the design of the software? Why do you think Smalltalk was good productivity-wise?

^Bizowie (bizowie.com)

>> On the other hand, I have to question the necessity of a custom ERP and the cost and effort put into it.

I can't imagine why anyone would, either. I've seen companies spend 2X the cost of a new ERP system that would solve all of their problems on customizations and additions to an existing, outdated ERP system.

What do they end up with? Solutions that are incomplete, unreliable, and late to the game.

fear of radical change people are more accepting of incremental changes rather than massive radical changes

rooted in fear of the unknown, i guess!!!

From what I've seen some clients like the control that building everything gives them. In practice this control might be illusory because of course they don't have the budgets to replicate everything they'd get from a big ERP package but NIH syndrome is certainly not exclusive to tech people.

Excellent point. A fear we see a lot in clients is that if the system's not built from scratch with them in mind, it can't do what they need. But the TCO of a system you build yourself is usually way higher than anticipated, due to project overruns and maintenance costs. It turns out software development isn't trivial, which is why we have companies that just build software.

Speaking from experience in having built a custom ERP system:

It's often easier to convince people to change software to suit existing business operations than to change business operations to suit existing software. Usually, the person in need of convincing to change the software is an employee who will get fired if they don't. On the other hand, it's often the president of the company you have to convince to change business practices. And he might not even be entirely on-board for "that software shit" anyway. Also, programmers make a living out of learning new things, so it comes naturally to us and we don't think twice about it. Everyone else in the company is set in their ways and had hoped "all that learnin'" ended in high school.

Every business is unique, and a custom solution can support that uniqueness, rather than the compromises that can need to be made with a (customizable) packaged solution.

I've seen one company write off a 100 million dollar investment in a Peoplesoft based replacement for a custom system, because it was realized that the compromises that solution required were becoming too great. Sure it was fabulous for 80% of requirements, but the other 20% became a giant sinkhole of money and pain.

Absolutely, if you have the budget to build, maintain, and support a custom ERP, it may be the way to go. But I think it's a tiny fraction of businesses where the benefits of that outweigh the extra costs involved. You have to be very large, and your issues with existing systems have to be pretty expensive, before that's the case.

Out of curiosity, do you know / can you share what kinds of problems caused the Peoplesoft investment to fall apart? What issues did they run into?

The District of Columbia Public Schools burned what must have been tens of millions on a Peoplesoft implementation some years ago. I guess they eventually got it running, but there was a lot of pain.

[Edit: I'm not sure DCPS was the part of the district government that felt the most pain.]

ERP is a tricky business.

10 Famous ERP Disasters, Dustups and Disappointments

http://www.cio.com/article/2429865/enterprise-resource-plann...

ERP Nightmare: Implementations Gone Awry

http://www.business-software.com/blog/erp-nightmare-implemen...

CIOs' next nightmare: legacy ERP

http://www.zdnet.com/article/cios-next-nightmare-legacy-erp/

10 ways to avoid an enterprise resource planning nightmare

http://www.bizjournals.com/bizjournals/how-to/technology/201...

It's because almost every business believes it's a special snowflake, and thus by extension so are its technology & process problems. Given that there's almost always somebody willing to sell them a custom solution who wants to make money reinforcing that delusion. It's not all that surprising that many, many non-tech or tangentially-tech markets end up saddled with a pile of proprietary hacked together garbage software and systems.

It's shockingly rare to encounter a Principal, CEO, or COO who goes into every business problem they have with a perspective like, "I know we're not an R&D company, so almost certainly our problems aren't pioneering efforts into the unknown frontier. Somebody must have encountered these issues before, so how can I capitalize on the fact that they must have already spent the money to resolve them?"

Historically, this has been especially true in investment banking, where every department, desk even, believes it's a special snowflake, and commissions their own solutions. High profitability exacerbated this. Increased regulation means lower margins, and proprietary solutions are declining.

Would the new ERP system solve all their problems without customizations and additions?

Interestingly, the first "extreme programming" project was a Smalltalk project (internal at Chrysler)

All these development practises originated in Smalltalk I believe. "Agile" software development itself was dreamt up by a bunch of (mostly) Smalltalkers. I heard once told that these practices were attempts at formalising/packaging and selling normal Smalltalk development practices.

Reply on news.ycombinator.com