Back in the tar pit?

I’ve now been involved with a couple of SAP HANA projects and I am left astounded.

Not only by the impressing performance and flexibility our product delivers for certain use cases.

I’m much more astounded by the expected level of software maturity of the final project implementations.

Yes, I’m not talking about SAP HANA as a DBMS platform but of the systems created on top of it.

Barely any of the projects included specific plans to design a maintainable system.

A system that can be meaningful monitored and eventually debugged.

Documentation of SQLScript code, modeled views and table design pretty much never exist.

Why did the designer of this CalcView decide to use plain SQL instead of CE_-functions?

What’s the rationale behind choosing this specific data type for that column?

How come this object is owned by user SAPDEV while the remaining ones all belong to MYAPPSCHEMA?

Answering this kind of questions requires having the actual developer still at avail.

Testing of views and procedures is done manually, if done at all.

Automatic testing with protocols?

Not existent.

Test data sets to verify functional correctness (at least for given cases)?

Never seen in any project.

Static and/or dynamic code analysis (How deep is your deepest function call stack you say? How many parameters you need to pass on average? What breaks if I change this part of your system?)?

Unheard of in SAP HANA circles.

This list can be extended with more and more points, but really irritating is the fact that apparently our paying customers are actually not asking hard enough for these things.

As it seems to me, they simply expect all this to be implicitly given. It’s a SAP system after all, isn’t it?

Fair enough or is it?

It seems the immaturity of SAP HANA as a platform is taken as a general excuse to throw over board the preceding decades of software engineering and craftsmanship. (You might pick the label you want to put on professional, reliable and reproducible work here yourself.)

Implementation teams happily and knowingly produce code that cannot be maintained efficiently.

Of course they do, as it will be their follow-up contract to fix and re-implement functionality.

Should the question come up, why the original code doesn’t do it anymore, it’s too easy to finger point at the lack of features and at instabilities of the development platform.

And is it just me or is the productivity of SAP HANA developers really that much smaller than that of their ABAP, JAVA or C# counter parts?

All this might work as long as the actual costs for the implementation aren’t bigger than the immense bill created by hardware and license costs.

Typically this means, round 1 of the implementation can fly under the radar of system quality, often leaving behind what could only be described as a mess.

No doubt, SAP HANA projects still are using a new platform. Many of the inherited best practices are questioned and some things needed to be changed.

But let’s not forget that in its very core, SAP HANA is a relational DBMS that exposes SQL as the main development API.

Now, how come that systems, that are built against an API that is 30+ years old, are implemented on such a unprofessional level?

Seriously, did just the fact that your IDE of choice doesn’t directly integrate with your version control system stop you from actually using it?

Did you consider using a SCRUM/agile approach with any other development environment that doesn’t allow for automatic testing?

I agree with most of the single feature demands seen here in SCN or communicated by customers and partners.

But I can’t agree with the lack of demand for a better system development practice.

And I certainly can’t agree with an approach where the goal to minimize system response time outweigh aspects like functional correctness and maintainability by several orders of magnitude.

The question is: why can you?