Wednesday, November 27, 2019

Parallax Scrolling

This seems to be old but gold: Parallax Scrolling.
It is an effect where you push content into different layers and scroll or move them in different speed.

You can see a demo here on w3schools: https://www.w3schools.com/howto/howto_css_parallax.asp


The things I found out during research (and that are really new to me) are:

- different speed means also zero speed (static background images are counted as parallax)
- it is not forbidden to create effects on scrolling (so eg: one image can be shown in different situations while the content in the background represents the scenes) AND this is also counted as parallax.
- parallax is still cool :-)



Saturday, April 13, 2019

Over Engineering

Over-Engineering is something most of the developers I know struggle with. Nevertheless, the term is also very subjective. What is over-engineered for developer A might be a perfect strategic step in the right direction for developer B. (in the following section the italic sentences are direct quotes from hackernoon here)

Over-Engineering is subjective and the damage of its subjectiveness increase as the requirements fail to present the full picture of the problem

So to define the term:

Over-Engineering is when someone decides to build more than what is really necessary based on speculation

So if we assume that speculation is the root cause then the following quote is the logical consequence:

To reduce the chances of considering something as Over-Engineering we need to understand the problem and to understand the problem we need to clarify the requirements as much as possible by asking "why"?

But there is more than that... Further Reasons (as described in cloud-foundry on youtube here):

  • consider the data
    • like:
      • how often are things used
      • how often are things changed
      • how long does a process take
      • is the process responsive
      • ...
    • we don't have it (green field, bad data gathering)
      • it might be too early to make a decision for further engineering (refactoring)...
      • will we have the data somewhen?
      • can we ask someone?
        • do we really trust this guy?
    • do we ignore the data and might make bad decisions
    • even if something is crap: 
      • is it worth changing it?
        • return of invest?
      • do we have use-cases that work out better by improving the software
  • unnecessary complexity because of pride
Further reasons (as described in build stuff-youtube here):
  • we are not listening to what we need to deliver (bicycle -> spaceship)
  • frameworks don't deliver value (even if funnier to solve any problem then one specific)
  • business guys are responsive to risk and not preventative so not implementing stuff might be ok for your product owner
  • don't focus on all the things that might go wrong, but recognize that you're still on the happy path (that nothing went wrong right now)