Categories
General

Does ‘software engineering’ even exist?

I’m not even sure if software engineering exists, or whether it should be called as such. See my opinionated post below.

How software emerged

As a reference, I have a ‘mechatronics engineering’ MSc, which is mostly a mix of electronics and mechanincal engineering. These classic engineering fields are called ‘engineering disciplines’.

Mechanical (and also civil) engineering is about 200 years old, electrical engineering is about 70-80. Whatever you’re designing, you’re leaning on the ‘shoulders of giants’, leveraging knowledge that may be more than a hundred years old.

Computer science has in fact branched from mathematics. In order to create computers and programming languages, we needed the computability notion of Turing completeness and the primal computer architecture (still holding today) envisioned by John Von Neumann.

Computer engineering, the practical side, kind of branched from electronics engineering, since software in first- and second-level programming languages were very close to the hardware.

You couldn’t just write an app in some high-level language, but rather needed to know a lot about low-level stuff like hardware architecture and CPU instructions.

Software gained huge traction in about 35 years ago, when personal computers became affordable, and embarked on a journey to eat the world. and now people call themselves ‘software engineers’. Heck, my employer calls me a software engineer!

Software engineering vs. hard sciences

Software engineering activities are similar to existing engineering practice in that you are modeling, measuring, researching and methodically refining a design in order to work towards some concrete end goal i.e. a software product. You can apply all the known engineering approaches and methods to design, implement, test and maintain software.

On the other hand, software engineering is totally different, much ‘softer’ (no pun intended) than mechanical, electrical, chemical or civil engineering that have something in common: they build on natural sciences.

In these classical disciplines, if you want to do something, you refer to some relevant physical or other scientific models, formulae, tables, standards whatever; get some results, maybe measure and simulate a bit and get a concrete result. Multiply by it some safety factor and there you go.

You can be sure because these standards and laws have been known for decades if not hundreds of years, they have been battle-tested in millions of applications. (Buildings, power and electronic systems, infrastructure, machinery, chemical processes etc.)

Compare this with software? Not so much. In that sense, it reminds me of non-natural sciences like social sciences or economics.

For each software problem to solve, you have 10 different languages, 100 frameworks, 20 totally different ‘paradigms’ with their own consultants, zealots and flamewars. Several could produce a satisfying solution to your problem, but they usually get replaced every 5 years.

Good old times?

5 years old software is called ‘legacy’, software that is 15 years old is often called a classic game or an anachronistic joke. Software expands like gas, taking up all available storage space and computing performance, but as time passes, in return we get many more layers of abstractions and a more complex development infrastructure. (Plus a nice UX, more ads and less privacy.)

We may think back of the ‘good old times’ when an operating system with several userspace software was able to run on e.g. a 233 MHz computer with 16 Mb of RAM (this was way after ‘640 kb was ought to be enough for anybody’). But we definitely don’t want to develop software the way it had been done back then, because we can create more, (maybe better) products, significantly faster.

As Uwe Friedrichsen puts it in his post about reusability:

…assume you need to build a not too challenging solution, e.g., a small e-commerce web shop that needs to run in a desktop browser and on mobile devices. If we leave aside for a moment that we can create such solutions today with tools like Shopify in a day or two, then this would be a task for a small team (5-7 persons) for 3-6 months.

But if you would need to start at the level of a bare programming language (3GL, turing-complete, no standard libraries, no ecosystem), this would be a daunting task: Probably a 100 or more people working for years, not knowing if they will succeed at all.

This enormous difference in productivity is the merit of reusability. If you needed string processing in C++ in the early 1990s, you needed to implement it yourself. Today, you start a whole HTTP server and more with a single line of code. This is reusability!

Uwe Friedrichsen, The reusability fallacy – Part 4

E for engineering, S for software

As we see, with classical engineering disciplines, the primary driver of progress was scientific research. Published in peer-reviewed journals, they meant a foundation for engineers to create well-documented and tested applications.

Software is changing much faster and it’s… well, soft.

  • We don’t have (natural) laws, we have ‘paradigms’ – one essentially never changes, the other apparently changes every few years.
  • We don’t have measurements, we have ‘metrics’ – we measure something but the goal is usually not to improve some model or control a system in a feedback loop, just to examine some system as it’s running, and restart it when it crashes…
  • We do have some standards (like ISO, ANSI), but compared to the speed of standards bodies, software is moving at a neck-breaking speed, and they are unable to catch up. Organizations like IETF and W3C represent ‘software standards’ much better, and work in a substantially different way.
  • We have some common terminology, but there is a lot of hype and buzzwords going around. The latest and greatest framework, architecture, language, paradigm, engineering method, whatever, promising easy and fast results. Of course.

Mother Nature doesn’t want to earn money on you when it comes to physical models. Consultants on the other hand do, when trying to sell their latest & greatest paradigms, ’10x’ engineering practices and lean methodologies.

Firms and managers can’t buy natural laws (though they do pay a lot to access ISO standards :)), but they love to rewrite their software into the latest and greatest architecture or framework, often without enough justification.

Summing up

What engineers/developers are doing may be similar to classical engineering practice but is way less exact. We may reason about programming languages, application architecture and business logic, but ‘clean coding’ practices and everyday ‘which library/framework should I use?’ questions are far from anything formal.

All in all, ‘software engineering’, although shows some similarities in approaching problems, is fundamentally different from existing classical engineering disciplines, changes much-much faster and probably we should come up with a better term for it, rather than abusing existing terminology.

I heard for example software craftsmanship… but I’m unsure.

What do you think about this?

Share this post
Categories
General

Self-taught software engineering: Coursera & co.

I really enjoy Coursera courses and have been doing them since I have been doing software engineering. It’s a great way to broaden my knowledge since I’ve never received formal computer science or software engineering education.

Just a quick update: I added a list of what I have completed to the About page.

Not really to brag; I guess one doesn’t spend countless hours at solving programming problems to just have a certificate to brag about. Okay, I’m fairly proud of these accomplishments, happily paid for the courses, and consider it time well spent.

Here’s a short post about what I have found out about these courses.

Share this post
Categories
General

My skills page is up!

Probably the longest self-description of one’s programming skills you’ve read in a while. Head right over there!

Share this post
Categories
Life Programming

Goals for 2020

It’s nice to have a list ready about what I would want to achieve this year. One is really ambitious of course, but this is something to refer back to later during the year, something to get inspired from in times of difficulty.

So here we go.

Share this post
Categories
Programming

Stress testing for “Data Structures and Algorithms” courses – Java & Python

I am doing the Data Structures And algorithms specialization on Coursera. (Which means every now and then I pick it up and make a few weeks of progress…) Started out with Python and now I’m switching to Java.

In this post I’ll show you how to set up stress testing, by generating random input data and comparing your implementation’s results to correct “naive algorithm” results.

I’ll also share a script that loads input from files and compares them to answers. This is useful for testing example inputs or pre-given tests for some exercises (usually where stress testing is not feasible)

Moreover, there is a GitHub repo with the ready-to-use solution.

Share this post
Categories
Programming

My Java experience as a Javascript developer

Motivation – why learn Java as a JS dev?

As a software engineer for about 2 years, I learned a lot. Starting out as a Typescript/Node.js developer, I quickly got the gripes of the Javascript world.

As we know, Javascript is a dynamically typed language, with an ‘objects linked to other objects’ (or prototype linking) approach. ES2015 adds some class-like syntax sugar on top which I personally don’t like, but frameworks such as Angular really embrace them.

Typescript adds static, compile-time type checking to the picture with a neatly engineered type system but it ultimately has no effect during run-time (apart from juggling with source maps).

I think that if as a developer you specialize in one or two languages, it’s still important to learn other languages, too, to widen your views and better understand general programming principles.

I believe general understanding turns you into a better engineer even if you don’t have a CS degree, plus it helps you pick up other tools of the trade (languages, frameworks) easier during your career.

Share this post
Categories
General

Hello!

My first blog post. If you are reading this, welcome! I’m happy that you are here.

I’m Gergely (Greg), a software engineer from Budapest, Hungary, who loves solving problems while at work (anywhere it catches me), hacking at home and boxing at the dojo. 😉

Why?

I decided to start a blog for multiple reasons:

  • Get stuff out of my head i.e. share useful information
  • Reflect on my journey as a professional software engineer
  • Connect with people
  • Find my own style and practice writing
  • Have my personal corner of the internet, aligning with my values about how the web should look like despite being an active developer of the modern web. 🙂

Expect posts every now and then, once a week by the least.

Upcoming stuff

Well, for starters:

  • A proper contact area
  • Add a photo of myself?
  • Expand the About page a bit with my personal creed
  • Create a skills list & roadmap to share my learning journey
  • Reflect on my current career goals and general experience as an enterprise employee

What now? Feel free to say hi in the comments and subscribe to my RSS feed. Sorry, no mailing list this time, but let me know if you would prefer an email notification.

Share this post