Changes for page General Insights

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -3,11 +3,9 @@
3	3	#### Economic Development
4	4
5	5	* **Economic Development Explained**: The ultimate goal of any software development effort is resource efficiency. In a business context, resources primarily mean money. That is, whether the topic is clean code, testing, architecture, agile, or even personal behavior as a professional, the goal is always to follow the **economic principle** of either achieving a fixed software goal using minimal resources (the **minimum principle**), or spending a fixed amount of time generating the most (business) value (the **maximum principle**). The goal is economic, the means to achieve it are technical. This means that the software engineer must think about the resources used for every technical decision, including typical business considerations such as cost-benefit and risk estimates. This is a valid business expectation for software engineers.
6		- * Minimum principle example: When implementing a feature - which is a fixed goal - the most cost-effective approach is chosen to get it done in the least amount of time.
7		- * Maximum principle example: The agile team tries to solve as many stories as possible in the time allotted for an iteration.
8	8	* **Sustainability**: Although economic development is too often misinterpreted as making short-term driven decisions, the actual goal is to achieve maximum profitability, which must include long-term considerations. In this way, time spent on maintaining high code quality through rigorous testing and refactoring are well spent investments that pay off in the long run.
9	9	* **Opportunity Costs**: Spend your time creating the most business value while considering all alternatives. An example is the decision whether or not to optimize performance. Implementing a new feature usually generates high business value, as does refactoring the code until it is clean. Tedious performance tuning, on the other hand, is often not necessary because the features are "fast enough". So the better alternative is often to spend time working on new features and only optimize performance when it is really necessary.
10		-* **Hobby Projects**: The main driver in a hobby project is usually having fun. Overly strict adherence to maximizing business value generation is contrary to the purpose of a hobby, which is to lightheartedly experiment, discover, or try new things. On the other hand, completely ignoring economics, e.g., not refactoring code, not testing, etc., will lead to development problems. The time it takes to make progress on a bad codebase becomes unnecessarily long, which is not a fun experience. This means that you should have fun with a hobby project, but my recommendation is to balance it with economic development so as not to lose the joy over time.
	8	+* **Hobby Projects**: The main drivers in a hobby project are usually not only fun, but also time spent on progress, and they are interrelated. Strict adherence to maximizing business value generation is contrary to the purpose of a hobby, which is to lightheartedly experiment, discover, or try new things. On the other hand, completely ignoring economics, e.g., not refactoring code, not testing, etc., will lead to problems. The time it takes to make progress on a bad codebase becomes unnecessarily long, which is not a fun experience. This means that you should have fun with a hobby project, but my recommendation is to balance it with economic development so as not to lose the joy over time.
11	11
12	12	#### Cost Considerations
13	13
...	...	@@ -20,7 +20,7 @@
20	20
21	21	* = Avoid making decisions you don't have to make right now.
22	22	* **The later we make decisions, the better informed they are.** Making a decision later reduces the chance of being wrong and therefore wastes fewer resources. For example, early in development it may be unclear whether the software should store data in a file or a database. Because persistence is not needed early on, the decision can be delayed by keeping everything in-memory. After 3 months, the customer requests that persistence be implemented next. Since the developers have learned a lot about the specifics of the project in that time and are better informed, the decision is much more likely to be a good one now than it would have been 3 months ago.
23		-* **Requirements evolve.** There are many reasons for this: customers refine their needs, planning and design did not work out as expected, new insights and problems emerge as the project progresses, and so on. This means that the effort put into the early requirements specification may turn out to be wasted later because the requirements have changed. Delay specification as long as possible, and specify technical details only when you have to. That is, think about or write down requirements for technical details during implementation, not before.
	21	+* **Requirements evolve.** There are many reasons for this: customers refine their needs, planning and design did not work out as expected, new insights and problems emerge as the project progresses, and so on. This means that the effort put into the early requirements specification may turn out to be wasted later because the requirements have changed. Specify only when you have them, delay specification as long as possible, i.e., specify just during implementation.
24	24
25	25	#### Miscellaneous
26	26
...	...	@@ -27,4 +27,4 @@
27	27	* **The sooner a problem is addressed, the cheaper it is.** For example, it is much cheaper to discover a problem in development than in production, where it could have caused real business damage. Or it is cheaper to refactor newly written code immediately, when you are familiar with it, than later, when you have forgotten it or someone else has to refactor it. So immediate refactoring, extensive testing, code reviews, and a focus on early feedback have become common practices.
28	28	* **Early Feedback Through Early Implementation.** Tasks like analysis, design, and specification don't provide feedback and therefore no correction mechanism. Without this, a lot of effort can be wasted on concepts that do not work. The first technical feedback comes during implementation. The first user feedback may come after implementation. This is why people use agile and work in iterations to start implementation as early as possible, get feedback as early as possible, and ultimately waste less resources.
29	29	* **Many small steps are cheaper than one big step.** It's more cost-effective to tackle a problem iteratively in small, simple, and safe steps than to tackle its full complexity all at once. That is why practices such as small-step refactoring, test-driven development, and continuous integration have prevailed.
30		-* **Individual productivity is higher in a team than when working alone.** A collaborative environment encourages knowledge sharing, professional growth, constructive challenge of individual views, mutual support and feedback. In addition, or if you have no one to talk to about technical issues, I highly recommend discussing problems and code with [ChatGPT 4+](https://chat.openai.com/) .
	28	+* **Individual productivity is higher in a team than when working alone.** A collaborative environment encourages knowledge sharing, professional growth, constructive challenge of individual views, mutual support and feedback.