DEV Community: Frank Puffer

What makes you post on dev.to?

Frank Puffer — Thu, 04 Apr 2019 17:59:51 +0000

As for me, it is mostly because I am interested in feedback from outside the bubble of people I work with every day. (I have to admit that, if the topic is appropriate, I still prefer Stack Overflow and some other Stack Exchange communities because I can reach more people there. On the other hand, most interesting questions are off-topic there.)

How about you? Especially those of you who put lots of work into uploading elaborate tutorials and essays.

OOP is great! And here is why!

Frank Puffer — Sat, 15 Dec 2018 21:49:07 +0000

My first impression of OOP, many years ago, coming from C programming: Cool, let's put everything into a class and declare some attributes. These are like global variables but without the bad smell. No more need to pass too many arguments around.

It took me a few years to find out that this is not the real benefit of OOP.

Unfortunately, when looking at OOP code today, many developers still seem to adhere to this mindset.

Unfortunately this is how OOP is still being taught at schools.

Can we avoid the bullshit bubble?

Frank Puffer — Wed, 12 Dec 2018 19:57:59 +0000

A lot of software development deals with integrating some badly designed system with another badly designed system, resulting in a system that is even worse to use and to maintain. At least that's what I have been observing during the last few years, mainly in the domain of so-called enterprise software.

Why is that? I am not sure but I guess it's because it generates revenue. It makes sense from an economical point of view. Crappy software is simply a sustainable source of income for some of us.

But is it healthy for the developers or the users? Even though it might sometimes be highly intellectually challenging to work on this type of project, I guess that most of us are not interested in doing just another bullshit job. Furthermore, this effect is bad for the reputation of our profession as a whole.

Did you make the same observation? Is there a way out?

(By the way, luckily most of my own projects do not belong to this category, however some of them do.)

What makes companies switch from SVN to Git?

Frank Puffer — Sat, 24 Nov 2018 21:56:55 +0000

The pros and cons of Git and SVN have been discussed abundantly for many years. So what makes me ask this question anyway? Most discussions compare certain technical aspects in detail but do not ask how relevant these actually are. I like to take the discussion to a more pragmatic level.

Let's face it. Most professional developers, including myself, are not really interested in version control. Of course they are aware that it is neccessary but they want to interact with it as little as possible and focus on their actual work instead. It is something that should more or less happen in the background. And of course as an employer you don't want the precious time of your developers to be spent on non productive stuff.

When comparing SVN with Git, it is pretty safe to say that the latter is much more complex. More things can go wrong. And they will go wrong and cost money.

Two examples:

In SVN there is your local data and a central repository. That's easy to understand and there is a single source of truth. In Git, there are multiple repositories. A local one and potentially multiple remote ones. But that's not all. There is also a staging area and a stash. While all of this makes sense theoretically, it gives the developer a lot of things to keep in mind. It definitely adds complexity to her life.
In SVN, commits have simple consecutive numbers while in Git there are 40 digit hashes. I understand that in a distributed version control system, a numbering scheme like in SVN is not possible. But then, who really needs distributed version control? Is being able to work offline really such a big deal nowadays?

You could add more items to this list, for example the cryptic command line interface of Git or the possibility to modify history.

So why do companies keep switching from SVN to Git and not the other way round?

Should Coding be Trivial?

Frank Puffer — Sun, 11 Nov 2018 15:43:38 +0000

This morning I listened to an interview with Leslie Lamport, a computer scientist who is also known as the initial developer of LaTeX.

One of his statements was that coding should be trivial. The complex stuff should be dealt with before coding, by writing specifications, by creating diagrams and by the use of modeling tools.

This is not the first time I hear such a statement. In fact I keep hearing them again and again. For quite a while I believed that this is the right approach to software development myself.

It just doesn't work, at least not effectively. And there are reasons for that.

When coding, you have excellent tools that provide instant feedback:

An IDE with syntax checking search functionality, autocompletion, refactoring tools and so on.
A compiler and linker or an interpreter that provide more or less descriptive error messages and warnings.
Debugging tools
Static analysis tools
Unit tests

These tools help you doing the right things and prevent you from creating bullshit.

When writing specificaltions or other design documents it is completely different. Your word processor doesn't care if what you type make sense. Neither does your favoutite diagramming tool. You have no feedback. As a result there will be errors in the design. These errors will only be found during implementation. (Normally the design documents will not even be updated, but that's another story.)

Now some people argue that the lack of feedback can be resolved by using modeling tools instead of word processors and diagramming programs.

There are modeling tools that seem to work well for specific tasks. Probably for relational database design. Maybe for state machine definition in embedded systems design. But I have not seen any modeling tool for general software development that comes even close to providing the benefits listed above. These things have been promised for at least 30 years and still don't seem to exist.

But what makes people so afraid of code? I don't know, but these possible reasons come to my mind:

This is what I call the write-only code mindset. People see code as the final product of the software industry. In most other industries, final products are extremely expensive to modify. I agree that this can also be the case with code - if the code is a mess - but it shouldn't be that way. That's why we have refactoring and code reviews.
People obsessed with design documents often don't code themselves or haven't coded for a very long time. Their notion of coding is like writing assembly instructions, maybe C or Fortran. They don't know about the level of abstraction and the expressiveness that modern languages offer with features like interfaces, modules, generics or higher order functions.

I don't argue against planning parts of the design before coding. I also understand that design documents are useful to communicate, especially with people who don't code. My point is that it is more efficient to do as much as possible in code and use external documents only if required.

Of course this only works if you take measures that prevent your code from turning into a mess. The most obvious are refactorings, code reviews, standards and of course coders that know what they are doing.

Note: These issues are less severe in agile development because the cycles are smaller but they still exist.