Is Programming hard ? It depends…

2 weeks ago while browsing my favorite website hacker news, I read this article saying that programming is hard.

I kindly disagree because for me, it depends…

But first what is programming ?

Fred Brook in his famous book There is no silver bullet wrote:

All software construction involves essential task, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental task, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints.

Designing complex conceptual structure is basically what software engineering really is. Coding is just an accidental task.

So for me, programming is actually:

Consuming abstractions produced by others and building our own abstractions on top of them to solve our own local business problem. This is what programming really is for me.

In my humble opinion, the difficulty of programming depends of both the layer of abstraction you are working on and the quality of the abstraction you chose to build to solve your problem.

The abstraction layer you depends on

All abstractions are not created equal. The quality of software abstractions can be ranked using various scales.

I read on the excellent blog of Terry Crowley that Abstractions can be classified using the following properties: Correctness, Consistency, Simplicity and Completness. I would add usefulness or power behind those abstraction. Software abstractions can be ranked using various scale but the ratio power to using them / cognitive price to use them is the one the most I used.

So let’s all together review some abstractions layer I had the opportunity to work within the last decade:

The good ones

Arkit

I have been playing a little with the abstractions coming from the Xcode/ArKit4 and SceneKit. Simple abstractions for the consumer which come with a lot of power behind them. With some moderate effort to leverage on the Arkit/SceneKit abstractions and the Iphone 12 Lidar, you end up with having a realistic reality augmented insect hiding behind your bed. Nothing really surprising here coming from Apple with top developpers producing simple but powerful abstractions and making it easy for us right ??

Angular

I have been for the last 5 years mainly implementing front end apps with both Angular and Angularjs.

AngularJS and Angular both tried to solve the same problem: building large javascript client while keeping the accidental complexity at the lowest.

I think we can all agree that while both frameworks allowed us to create large front end application, the accidental complexity of an application built with AngularJs is higher than one built with Angular. Angular is actually easier than AngularJS while bringing to the table abstractions with way more power to the frontend developer. It takes just the official angular’s tutorial to have a backend dev producing efficiently angular component. It’s harder with AngularJs. While switching from javascript to typescript helped a lot, top google devs refined the new Angular framework to give us more powerful abstractions requiring less cognitive a power to play with.

.Net Core/ Azure stack

I might be biased on this one, because I have been working mainly with the .Net stack for the whole decade but to me the whole MS .Net Core / Azure thing is really powerful and simple.

From CosmoDB, the Azure Cognitive Search etc.. Microsoft Top devs came strong with all those powerful abstractions, partially solving for us hard problems like scalability, availability, reliability etc…

While Serverless abstractions are available with all main cloud providers, Azure Function are simply so powerful, simple and well design. You can implement REST APis with the whole CI/CD pipeline setup within a day, allowing us developper to focus on real business problem. Thanks to Power Apps or to certain extents Logic Apps, Non-developer people can actually model business process into software workflow with ease.

and now…

The bad ones

The custom dreaded wrapper abstraction

Im pretty sure at one point in our career, we all met those custom enterprise abstractions named commonly wrapper. it always start with somebody saying something like:

Yeah I made a custom wrapper for this well known and well tested framework and it really will help at that.

and obviously there is no way around, you have to use it.

While probably allowing the enterprise or the architect to enforce, policies threw the code of those custom wrappers for all company’s developers, usually those abstraction wrappers bring nothing to the table but pain and sorrow.

In the last decade, I had to work with several custom made wrappers built on top legit abstractions and I could write 10 pages on it but usually they share the same core properties:

• no real power behind them while cognitively pricey to understand and use
• no documentation
• no web community support
• life cycle which doesn’t follow the underlaying abstraction layer
• end up thrown away if possible when the main developers behind them finally leave the team. if not possible the whole project is thrown away because obviously those abstractions don’t age well

The custom AngularJs Wrapper thing

For example, I have seen custom abstractions wrapper around AngularJS, hiding completely native abstractions, coming with little to no documentation which means that you had simply to throw to the window whatever knowledge you had on angularjs to master this new framework. You ended up needing one day to just to create a single a button to a login page. The whole framework was thrown away.

Entity Framework Functional Abstraction madness

I have seen a big custom functional framework providing abstractions built on top on Entity Framework ( like entity framework was not hard enough ) to try to mimic functional development pattern in c#. You had function currying, monad, etc… Let alone the developer who built that had no knowledge of how entity framework contexts where actually working. It could take 4 hours to load 1000 rows in a SQL table. Those abstractions were leaky in all types of way possible. Usefulness and performance close to zero. Those abstractions were so poorly implemented and so buggy, that one point no one could really distinguish bugs from feature. The project was thrown away.

The Sharepoint list Nightmare

I have been part of a team of five seasoned Sharepoint developers where we had to develop a web solution on top of Sharepoint 2010. All displayed labels were coming from a big abstraction able at runtime to decide what to display dynamically. Its seems we had the requirement to support multiple language and we were forbidden to go with usual technique involving localized resource files. That abstraction — implemented on the top of Sharepoint lists — ended up recreating sql left join and inner join at the Sharepoint layer abstraction level.

A single page could take two minutes to display two images and a description text box. We ended up applying half of your regular average PHD advanced discrete mathematics book to solve performance issues without even having a tenth of the kind of data volume the application was supposed to handle. After 6 months of struggle, the project was abandoned.

Conclusion

The difficulty of programming depends on:

• The quality of the layer of abstractions that you are building your custom abstractions on top of
• The quality of abstractions you are building to solve your problem which closely relate to what is your comprehension of the problem you are trying to solve in the first place

So is programming hard ? To me it depends …

Sorry for my english, I’m not a native speaker.

Okossa