new article

content/posts/feature-production.md

@@ -0,0 +1,65 @@
+---
+title: "Feature Production"
+date: 2024-02-02T07:29:33+01:00
+draft: true
+---
+
+# My engineers output is slower than ever
+
+There is a catch that is never really explained in agile methodology, and is inherent to any software development lifecycle.
+
+It is always slowing down, one day or another, and *significantly* so.
+
+Your velocity will crash. Either your estimates will inflate, or the velocity will drop. Less and less features get out.
+
+We will cover here what is that phenomenon about and how to act upon it.
+
+## What deciders have to understand about it
+
+A product becomes increasingly complex as it develops. A product keep doing more and more different things, in a more and more robust way.
+
+This increasing level of demand on your output raises the bar for what is demanded for the developer to know before entering a coding session.
+
+The product context, the stregthened process, the increasing base of potential existing product interaction pitfals, the overall technical layers to know and to respect quality level on (logging, tests, architecture etc.) are as many increasing weights a developer must lift. 
+
+This is not to be underestimated: this will lead to slower developer training, increasing number of mistakes in development flow, and even bore and burn outs, who sporadingly show themselves in the dress of "We should have a project friday" a.k.a. dedicated time to start fresh without the mental strain to code on the main thing.
+
+The worst part? This is ineluctable. Development leads to having things developed already. No magic methodology can trick you away. No clever code architecture. No given process or management technique.
+
+However, there are some answers that are to be found to ease the pain.
+
+## Tips and tricks
+
+### Product
+
+Admit mistakes: simplify your product. Streamline the value from your software. If something stops bringing enough cash, cut it.
+
+There is a mirage that a feature cost is estimated by its dev time. This is fundamentally wrong. A feature keep costing after development, for all the bugfix, security maintenance and other costs are to be spent maintaining it afloat. The sheer existance in your codebase of something that isn't necessary, costs money. The product must remain as simple as it can possibly be.
+
+Shift paradigm: at a given team size, there is a finite number of features you can provide. Choose wisely.
+
+### Code
+
+There is nothing really new here, but code maintenance must be held at high standard. Good architecture must be well cut in blocks, that different people will be in charge of maintaining, to reduce the amount of knowledge that is necessary for one to know from the overall frame.
+
+The best engineers know and will have a plan for this. Be sure to have them, divide and conquer.
+
+### Time management
+
+A company should have a generous portion of their development time dedicated to tackling technical debt. That can be: architectural debt, data modeling changes, infrastructure. We're not even speaking about bugs, we're talking about things that do not impact anything at the functional level (except for a performance increase here and there). 1/4 - 1/3rd of the time can be good amounts, and the earlier you do it, the better you have returns for it.
+
+This sounds like a cash burn to some non-technical deciders, but amazingly enough, once you start asking the team, digging for things that can be improved at the same perimeter, you usually find a ton of stuff. You will make your developers empowered and valued as you will enable them to ideate and carry on things that can save a ton in the long run.
+
+Having less time for features also means you might have to choose them with a little more recoil.
+
+### HR
+
+Because when a knowledgeable developer goes, their knowledge is lost, it's important to manage turnover. That doesn't necessarily mean throwing a lot of cash, but that means paying decently. Once that is sorted, the company should strive to offer good working conditions, and proactively remove anything that can be toxic in the environement, like micromanagement, harrassment, bro culture etc.
+
+Interpersonal respect must be taken care of by everyone and managers have to be examplary. Frequent 1-on-1 will enable higher ups to keep in check with individually varying needs. 
+
+## Final words
+
+I wrote this article frustrated by the idea that many methodology conveys that producing features is similar to a factory output. Nothing could be more wrong. A software is a shared ownership living entity, that each and everyone have responsibility in how they impact it, and business goals are only one part of that input. A software with "more features" isn't a better software: many softwares are, on the contrary, praised for *being the best at what they do*. 
+
+I believe as a SaaS company, this should be the common, unifying goal, rather than measuring an output. And perhaps, if your output is slowed down, it means you work for the quality of the output more than you were before?

public/index.xml

@@ -1,5 +1,52 @@
-<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Diane M's blog</title><link>https://princess-entrapta.github.io/blog/</link><description>Recent content on Diane M's blog</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Wed, 01 Nov 2023 19:31:16 +0100</lastBuildDate><atom:link href="https://princess-entrapta.github.io/blog/index.xml" rel="self" type="application/rss+xml"/><item><title>Developers Work From Home</title><link>https://princess-entrapta.github.io/blog/posts/work-from-home/</link><pubDate>Wed, 01 Nov 2023 19:31:16 +0100</pubDate><guid>https://princess-entrapta.github.io/blog/posts/work-from-home/</guid><description>After presenting developers work from home data, I will present key opportunity and challenges that arise from it. I will then conclude with personal opinion and recommendation regarding work for home for developers.
+<?xml version="1.0" encoding="utf-8" standalone="yes"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+  <channel>
+    <title>Diane M&#39;s blog</title>
+    <link>https://example.com/</link>
+    <description>Recent content on Diane M&#39;s blog</description>
+    <generator>Hugo -- gohugo.io</generator>
+    <language>en-us</language>
+    <copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright>
+    <lastBuildDate>Wed, 01 Nov 2023 19:31:16 +0100</lastBuildDate><atom:link href="https://example.com/index.xml" rel="self" type="application/rss+xml" />
+    <item>
+      <title>Developers Work From Home</title>
+      <link>https://example.com/posts/work-from-home/</link>
+      <pubDate>Wed, 01 Nov 2023 19:31:16 +0100</pubDate>
+
+      <guid>https://example.com/posts/work-from-home/</guid>
+      <description>After presenting developers work from home data, I will present key opportunity and challenges that arise from it. I will then conclude with personal opinion and recommendation regarding work for home for developers.
 Key data Stack overflow 2023 developer survey disclosed that:
-42% respondants developers work in totally remote environment 42% in hybrid environment, mixing in office and remote work 16% in fully in-office. Self-employed developers work remotely for 70% of them.</description></item><item><title>Green It</title><link>https://princess-entrapta.github.io/blog/posts/green-it/</link><pubDate>Fri, 27 Oct 2023 18:53:49 +0200</pubDate><guid>https://princess-entrapta.github.io/blog/posts/green-it/</guid><description>Some figures about IT and the environment Electronic devices and other IT related activity represent 4% of the total global carbon footprint, a figure that is growing every year due to sector growth. If the proportion may look small, it actually is important regarding other industry sectors; automobile sector, known for its pollution side effects, in its whole is for example estimated weighting roughly 6 to 9% of global carbon emissions.</description></item><item><title>Dockerfile for small Rust images (with dependency build caching)</title><link>https://princess-entrapta.github.io/blog/posts/build-rust-dockerfile/</link><pubDate>Wed, 25 Oct 2023 12:56:00 +0200</pubDate><guid>https://princess-entrapta.github.io/blog/posts/build-rust-dockerfile/</guid><description>Introduction After reading multiple tutorials for building docker images and optimize them, I compiled an optimized Dockerfile that can:
+42% respondants developers work in totally remote environment 42% in hybrid environment, mixing in office and remote work 16% in fully in-office. Self-employed developers work remotely for 70% of them.</description>
+    </item>
+
+    <item>
+      <title>Green It</title>
+      <link>https://example.com/posts/green-it/</link>
+      <pubDate>Fri, 27 Oct 2023 18:53:49 +0200</pubDate>
+
+      <guid>https://example.com/posts/green-it/</guid>
+      <description>Some figures about IT and the environment Electronic devices and other IT related activity represent 4% of the total global carbon footprint, a figure that is growing every year due to sector growth. If the proportion may look small, it actually is important regarding other industry sectors; automobile sector, known for its pollution side effects, in its whole is for example estimated weighting roughly 6 to 9% of global carbon emissions.</description>
+    </item>
+
+    <item>
+      <title>Dockerfile for small Rust images (with dependency build caching)</title>
+      <link>https://example.com/posts/build-rust-dockerfile/</link>
+      <pubDate>Wed, 25 Oct 2023 12:56:00 +0200</pubDate>
+
+      <guid>https://example.com/posts/build-rust-dockerfile/</guid>
+      <description>Introduction After reading multiple tutorials for building docker images and optimize them, I compiled an optimized Dockerfile that can:
 Have final images that are small, in the 50MB range Benefit from docker caching, allowing to have build times under 10s if you don&amp;rsquo;t change dependencies We will assume here you start with a project my_app you already have or have created with cargo new.
-Setting up We use this docker file.</description></item><item><title>About Me</title><link>https://princess-entrapta.github.io/blog/about-me/</link><pubDate>Wed, 25 Oct 2023 00:00:00 +0000</pubDate><guid>https://princess-entrapta.github.io/blog/about-me/</guid><description>Coming soon</description></item></channel></rss>
+Setting up We use this docker file.</description>
+    </item>
+
+    <item>
+      <title>About Me</title>
+      <link>https://example.com/about-me/</link>
+      <pubDate>Wed, 25 Oct 2023 00:00:00 +0000</pubDate>
+
+      <guid>https://example.com/about-me/</guid>
+      <description>Coming soon</description>
+    </item>
+
+  </channel>
+</rss>