Changes for page General Insights

Summary

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

Details

Page properties

Content

...	...	@@ -1,15 +1,15 @@
1		-While reading the software engineering literature, I noticed that there are a few high-level principles that run through many technical topics and are the driving force behind many developed best practices. Since I found them useful, I would like to summarize them here in a short and clear form.
	1	+While reading the software engineering literature, I noticed that there are a few high-level principles that run through many technical topics and are the driving force behind many developed best practices, workflows, and models. Since I found them useful, I would like to summarize them here in a short and clear form.
2	2
3		-* **The ultimate goal of any software engineering effort is resource minimization.** 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 make everything related to software as cheap as possible. 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 expectation for business to have of software developers.
	3	+* **The ultimate goal of any software engineering effort is resource minimization.** In a business context, resources primarily mean money/costs. That is, whether the topic is clean code, testing, architecture, agile, or even personal behavior as a professional, the goal is always to make everything related to software as cheap as possible. 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 expectation for business to have of software developers.
4	4	* **Cost Considerations**
5		- * **Most costs are caused by maintenance, not development.** Quick and dirty development never pays off, not in the short term and even less in the long term.
6		- * **Hardware is cheap.** When software is deployed on a single server, hardware costs are usually negligible. However, when the same software is deployed on a large number of servers, the importance of hardware costs can increase.
7		- * **Staff is expensive.** Salaries for software developers are high, and highly skilled people are rare. Be aware of this resource and take appropriate measures, such as investing time early in good code design to reduce the amount of development and maintenance staff needed.
8		- * **Performance is often secondary.** While it feels good to write highly efficient code, in many cases it is not necessary. Fast is often fast enough, and perfect is overkill. Just put enough effort into performance optimization to meet the project's needs. Since most programming languages are fast enough for most use cases, it is better to choose the language based on the experience of the development team and the requirements of the project rather than on performance.
9		-* **Delay Decisions.** Avoid making decisions you don't have to make right now.
10		- * **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.
11		- * **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.
12		-* **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.
	5	+ * **Most costs are caused by maintenance, not development.** Quick and dirty development never pays off, neither short term and even less in the long-term.
	6	+ * **Hardware is cheap.** When software is deployed on a single server, hardware costs can usually be neglected. However, the importance of hardware costs may increase when the same software is deployed on a large number of servers.
	7	+ * **Staff is expensive.** Software developer salaries are high and highly skilled people are rare. Be considerate of this resource and take according measures like investing time into good design and maintainability of the code from early on.
	8	+ * **Performance is often secondary.** Though its a good feeling to write highly efficient code, in many cases it is not necessary. Fast is often fast enough and perfect would be overkill. Just put as much effort in performance optimization to meet the project requirements. Since most languages are fast enough for most use cases, the language is better chosen by the experience of the developer team.
	9	+* **Delay Decisions.** We should avoid making decisions that we don't have to make right now.
	10	+ * **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, at the beginning of development, it may be unclear whether the software should store data in a file or a database. Since persistence is not needed early on, the decision is delayed by keeping everything in-memory. After 3 months, the customer requests that this feature be implemented next. The decision is now much more likely to be a good one than it would have been 3 months ago.
	11	+ * **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 before implementation.
	12	+* **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 newly written code is cheaper to refactor immediately, when you know it, than later, when you have forgotten all about it or someone else has to refactor it. Thus, immediate refactoring, extensive testing, code reviews, and a focus on early feedback have become common practices.
13	13	* **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 feedback comes during implementation. The first user feedback comes 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.
14	14	* **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. This is why practices such as test-driven development and continuous integration are popular.
15	15	* **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.