1 files changed, 0 insertions, 37 deletions
diff --git a/not-a-book/occams-razor.tex b/not-a-book/occams-razor.tex
deleted file mode 100644
index 4694dc7..0000000
--- a/not-a-book/occams-razor.tex
+++ /dev/null
@@ -1,37 +0,0 @@
-\chapter{Follow Occam’s razor whenever you can}
-\section{What is Occam’s razor}
-Occam’s razor (or Ockham’s razor) is a principle from philosophy. Suppose there exists two explanations for an occurrence. In this case the one that requires the least speculation is usually correct. Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation. Occam’s razor applies especially in the philosophy of science, but also more generally.
-\section{How I apply Occam’s razor}
-For me this principle means, if we have a problem we normally have multiple solutions for it and the most simple solution is usually the correct one. Sometimes this is not possible but in that case all solutions are usually complex ones.
-I have learned that complex solutions don’t translate well into reality and introduce a lot of moving parts and systems with a lot of moving parts break apart easier.
-This is one of the reasons I have been and still am very conservative with micro-services. They are amazing, no question about it. But people can go too far with them. And then you end up with an insanely complex system relying on crazy amount of inner-service communication. There is a reason why GNU Hurd was never finished. Managing this complexity moves accountability away from developers and increases pressure on DevOps.
-\section{Uncertainty vs. clarity}
-Most of the projects I observed never went beyond discovery phase in matters of clarity. They just assumed that the first explanation for a solution is good enough. Discovery phase was there just to add billable hours and boilerplate text was added to the documents.
-We threat project documentation like legal documents which is just idiotic and in the end this hurts project immensely. There is a place for legal text but not in a specification documents.
-I understand that client can be sneaky and can try to push feature creep into the project. I totally get it. But all this could be fixed by having an appendix to the document explaining rules on how to read this document. That being vague does not permit anybody to start adding additional functionalities to specs.
-The amount of times I have sat on meetings when we went from "Client wants a form on his page" to "There should be a short animated film here explaining XYZ" astonishes me. Now that I look back I really wonder how was I able to listen to this without loosing my mind. And I was even an active participant digging my own grave most of the time by accepting a task without properly thinking about it. Getting swept by brainstorming session. I have learned this lesson the hard way.
-\section{Showcases and marketing}
-There seem to be this disconnect between reality and what I call a Lala Land where people in places of authority don’t really even take the time to properly analyze their requests.
-On multiple occasions I witnessed first hand somebody coming with an idea they saw on Google I/O video or some other conference they visited some or even read about it in a marketing blog and tell everybody on a team that this is the future and we must go into this direction.
-Well, nothing wrong with that in general. I am all for progress. But what bothered me was their lack of listening skills. Specially when team lead started to explain that it took them 6 months and a team of 10 developers to accomplish this task. And they want to have it done in a week or two. Preferably by Friday morning so they can talk about it while sipping coffee in the morning. Back to the dungeon you go.
-It’s mind-boggling. How in the hell didn’t you listen to that part also. I find it amazing how people get caught in shiny things. And this type of people are very vocal when it comes to their territory. You don’t understand. Writing code is the easy part. Try to write a proposal. You need to have this high-level perspective and you must be able to bla bla bla. I always just zone out. I have written proposals and I can say that they were far more structured and organized with proper info in proper places.
-It doesn’t take a genius to write a proposal. And it doesn’t take a genius to write code. All it takes is good personal organization and knowledge about the field which can be learned.
-I don’t mean to over simplify things but to say that this things are just for the most intellectual ones is just absurd and it doesn’t serve anybody any good.

diff --git a/not-a-book/occams-razor.tex b/not-a-book/occams-razor.tex deleted file mode 100644 index 4694dc7..0000000 --- a/not-a-book/occams-razor.tex +++ /dev/null
@@ -1,37 +0,0 @@
1	\chapter{Follow Occam’s razor whenever you can}
2
3	\section{What is Occam’s razor}
4
5	Occam’s razor (or Ockham’s razor) is a principle from philosophy. Suppose there exists two explanations for an occurrence. In this case the one that requires the least speculation is usually correct. Another way of saying it is that the more assumptions you have to make, the more unlikely an explanation. Occam’s razor applies especially in the philosophy of science, but also more generally.
6
7	\section{How I apply Occam’s razor}
8
9	For me this principle means, if we have a problem we normally have multiple solutions for it and the most simple solution is usually the correct one. Sometimes this is not possible but in that case all solutions are usually complex ones.
10
11	I have learned that complex solutions don’t translate well into reality and introduce a lot of moving parts and systems with a lot of moving parts break apart easier.
12
13	This is one of the reasons I have been and still am very conservative with micro-services. They are amazing, no question about it. But people can go too far with them. And then you end up with an insanely complex system relying on crazy amount of inner-service communication. There is a reason why GNU Hurd was never finished. Managing this complexity moves accountability away from developers and increases pressure on DevOps.
14
15	\section{Uncertainty vs. clarity}
16
17	Most of the projects I observed never went beyond discovery phase in matters of clarity. They just assumed that the first explanation for a solution is good enough. Discovery phase was there just to add billable hours and boilerplate text was added to the documents.
18
19	We threat project documentation like legal documents which is just idiotic and in the end this hurts project immensely. There is a place for legal text but not in a specification documents.
20
21	I understand that client can be sneaky and can try to push feature creep into the project. I totally get it. But all this could be fixed by having an appendix to the document explaining rules on how to read this document. That being vague does not permit anybody to start adding additional functionalities to specs.
22
23	The amount of times I have sat on meetings when we went from "Client wants a form on his page" to "There should be a short animated film here explaining XYZ" astonishes me. Now that I look back I really wonder how was I able to listen to this without loosing my mind. And I was even an active participant digging my own grave most of the time by accepting a task without properly thinking about it. Getting swept by brainstorming session. I have learned this lesson the hard way.
24
25	\section{Showcases and marketing}
26
27	There seem to be this disconnect between reality and what I call a Lala Land where people in places of authority don’t really even take the time to properly analyze their requests.
28
29	On multiple occasions I witnessed first hand somebody coming with an idea they saw on Google I/O video or some other conference they visited some or even read about it in a marketing blog and tell everybody on a team that this is the future and we must go into this direction.
30
31	Well, nothing wrong with that in general. I am all for progress. But what bothered me was their lack of listening skills. Specially when team lead started to explain that it took them 6 months and a team of 10 developers to accomplish this task. And they want to have it done in a week or two. Preferably by Friday morning so they can talk about it while sipping coffee in the morning. Back to the dungeon you go.
32
33	It’s mind-boggling. How in the hell didn’t you listen to that part also. I find it amazing how people get caught in shiny things. And this type of people are very vocal when it comes to their territory. You don’t understand. Writing code is the easy part. Try to write a proposal. You need to have this high-level perspective and you must be able to bla bla bla. I always just zone out. I have written proposals and I can say that they were far more structured and organized with proper info in proper places.
34
35	It doesn’t take a genius to write a proposal. And it doesn’t take a genius to write code. All it takes is good personal organization and knowledge about the field which can be learned.
36
37	I don’t mean to over simplify things but to say that this things are just for the most intellectual ones is just absurd and it doesn’t serve anybody any good.