Projects, Architecture, Stack, Frameworks, CI

The Art of Over Engineering Your Side Projects - Wow, this is lovely topic. Let's see what I think about the article.

1. Project Management - All very true, it's easy to create huge backlog of all kind of nice to have bells and whistles. Yet you'll never find time to get those completed. Been there, done that. Obviously.

2. Over-architecting infrastructure - This is something which I've been actually pretty good at avoiding. I like simple solutions and therefore also don't like over-architecting, for projects that should be deliverable. And I do really prefer running on bare minimum, especially in cases where I'm paying the bills for the infrastructure. Of course if it's "I just want to learn about project", then whole poitn of the project can be over-architecting the stack and infrastructure and as soon as that's done, or working at some prototype level, I'll discard whole project. I've learned what I wanted to learn, how to use technology X or platform Y successfully. I can use it later and continue from this point, if required. Job done.

3. Worrying about "tech stacks" - No, I don't. I use usually some light and simple stack, which will get the job done. Because the heavy and complex stacks also often require amazing amounts of time to learn. But if learning that stack X is the goal itself, then it's different story. - Aka building a project to learn X. Which is actually very valid way of learning. Often people ask how do I learn something. Just make a project Y and accomplish it using technology X. It forces you to learn necessary stuff to get it working. - This is the method I prefer.

4. Creating custom frameworks - No not own frameworks, but yes. I do often write quite a bit of 'basic core code' which could come from some other library. But I do that only for stuff I want to learn about and usually the parts are very small after all. As example the PyClockPro library was written to learn about Python and to learn in detail how CLOCK-Pro cache works. People often claim that they know how something works, but when you ask them to implement it, they fail. So they didn't actually know how it works.

5. Continuously delivering nothing - Continuous Delivery and Continuous Integration are things which I've done just to learn about the details. But to be honest, I haven't ever used either of those for light production projects, where the actual goal is to deliver and time is money. - When time is money, simplicity and robustness is the key. At some time efficiency could count, but unfortunately (?) often it doesn't. If I tell customer that I could refactor this to gain 50% speed improvement and it'll cost you, they'll probably decline it anyway. Until the implementation performance becomes a very real problem. Like daily ETL tasks not running in 24 hours.

It's kind hard to sell something like: You'll get nice cleaner code, which also includes nicer logs and exception handling for extremely rare events. I'll do that for 15k€. When the customer asks, if they see any difference. My answer is nope, that won't deliver any practical value to you. - I wonder why they won't be ordering the job. As well as then someone can complain that something non essential isn't optimized, nor very rare exceptions aren't handed properly. Actually what properly means varies. I usually always have code, which leads in situation of "unexpected exception" to either the message / packet getting discarded, if that's a better option. Or if order must be maintained, then clear log entry and alerts what went wrong and the whole process is stopped until the issue is fixed somehow.

Just once again, wondered how many online services don't want to use strong authentication. It's possible, but they actively refuse to use it. Even major players don't use it. Usually only organizations which guard really high value data choose to use strong authentication. Either using their own infrastructure, national infrastructure or 3rd party infra.

Noticed some issues with some sites and content, which have to be cleaned up. Wow, this is true Everything / Nothing entry. You don't know what I'm writing about, and that's supposed to be that way for now. but I'm very serious about it anyway.

2018-12-23