Automated updates: 2021-01-27

2020-08-22-pentagon.md

@@ -5,13 +5,13 @@ date: 2020-08-22 07:09:12-0400
 categories:
 tags: [freeculture, bookclub]
 summary: Discussing Pentagon
-thumbnail: /blog/assets/pentagon-2008-the-hill-productions.jpg
+thumbnail: /blog/assets/pentagon-2008-the-hill-productions.png
 offset: -34%
 ---
 
 This week, our [Free Culture Book Club]({% post_url 2020-05-02-freeculture %}) digs into **Pentagon**, the debut production from The Hill Productions, "a no budget, DIY, independent film production and distribution company."
 
-![Pentagon movie poster](/blog/assets/pentagon-2008-the-hill-productions.jpg "Pentagon movie poster")
+![Pentagon movie poster](/blog/assets/pentagon-2008-the-hill-productions.png "Pentagon movie poster")
 
 To give this series some sense of organization, here are some basic facts without much in the way of context.
 

2020-09-20-pronoun.md

@@ -22,11 +22,11 @@ First, if you need an overview of what role a pronoun serves, try [the article o
 
 That's not to say that I've completely convinced myself to share my pronouns.  It occurs to me that the messaging around sharing one's pronouns is pretty terrible.  Every discussion I can find spends what I would call an inordinate amount of time explaining pronouns in general, quickly points out the importance of pronouns to transgender and non-binary people, spends more time explaining how to share them (which---purely coincidentally, I assume---always recommends linking to them), may or may not talk about whether it's a good idea to ask people to share their pronouns, and...that's it.  Maybe they'll sneak in mention that "it's more welcoming" with no further interrogation.
 
-It also feels comparable to---though obviously not the same as---[cultural appropriation](https://en.wikipedia.org/wiki/Cultural_appropriation), in that it takes something that is special to an oppressed minority and pushes it into wider adoption without the context that makes it important.  Specifically, it turns gender identity into a box to performative check on a checklist.
+It also feels comparable to---though obviously not the same as---[cultural appropriation](https://en.wikipedia.org/wiki/Cultural_appropriation), in that it takes something that is special to an oppressed minority and pushes it into wider adoption without the context that makes it important.  Specifically, it turns gender identity into a box to performatively check on a checklist.
 
 Likewise, there's an unmistakable resemblance to the people who shout "[All Lives Matter](https://en.wikipedia.org/wiki/All_Lives_Matter)," too, in that it feels like an attempt to assert that my pronouns "matter."  They don't, not even to me, and certainly not to the degree that someone else's pronouns matter in this context.  So who am I to interject my pronouns into the conversation?
 
-Finally, as I mentioned a couple of paragraphs back, there is concern about pressuring people into disclosing the pronouns that they feel are correct for them.  In formally publishing my pronouns, I wouldn't want to contribute to an environment that pushes past "it's OK for you to do so" and into "you should do so" territory.  This connects with other gender issues, like drawing attention to the presence of women after decades of fighting the unhealthy perception that women are alien to or invaders in certain spaces.
+Finally, as I alluded to a couple of paragraphs back, there is concern about pressuring people into disclosing the pronouns that they feel are correct for them.  In formally publishing my pronouns, I wouldn't want to contribute to an environment that pushes past "it's OK for you to do so" and into "you should do so" territory.  This connects with other gender issues, like drawing attention to the presence of women after decades of fighting the unhealthy perception that women are alien to or invaders in certain spaces.
 
 In other words, it feels to me like it's a step about me and that it conflicts unpleasantly with how feminism traditionally works.
 

2021-01-27-estimate.md

@@ -0,0 +1,125 @@
+---
+layout: post
+title: How Long Will That Project Take?
+date: 2021-01-27 07:26:23-0400
+categories:
+tags: [techtips, programming, management]
+summary: A quick discussion of how estimates work
+thumbnail: /blog/assets/writing-work-architecture-pen-train-architect-819794-pxhere.com.png
+offset: -38%
+---
+
+Every once in a while, I'm reminded that one of the most important tasks in software development that most developers never learn to do is to estimate projects.  Interestingly, rather than drawing from other disciplines to teach people how to produce better estimates, the industry has shifted to management techniques that assume that estimates are going to be embarrassingly wrong.
+
+![Preparing to Estimate](/blog/assets/writing-work-architecture-pen-train-architect-819794-pxhere.com.png "Preparing to Estimate")
+
+So, since the topic has come up a couple of times in the past few weeks, I wanted to centralize my thoughts, in case they're useful to someone else.
+
+## Estimating or Guessing
+
+To start off, let's be clear that a project estimate isn't hearing a quick description of the finished project and picking a number that "sounds about right;" that's a guess.  There are cases where guesses are acceptable, and your guess might be right, but estimates are something different.
+
+Let's do the dumb "the dictionary defines..." thing, here, borrowing from [Wiktionary](https://en.wiktionary.org/wiki/estimate).
+
+ > **estimate** (third-person singular present **estimates**, present participle **estimating**, simple past and past participle **estimated**)
+ >
+ > 1. To calculate roughly, often from imperfect data.
+ >
+ > 2. To judge and form an opinion of the value of, from imperfect data.
+
+Those are basically the same thing in different contexts, and I hope it shows the distinction between estimating and guessing.  Your estimate *would be* the correct answer, if you had better information.  Your guess would probably not change.
+
+## Fudge Factors
+
+While, again, guessing is fine in certain environments, it has a huge weakness:  To try not to over-promise, workers (especially software developers, in my experience) tend to try to find some magic multiplier that will turn their fantasy number into a valid number.  It doesn't work, but that doesn't stop people from hoping to make the proposed time-frame long enough to sound credible, but short enough for the investment to sound like a good bargain.
+
+In my experience, these factors come in a small handful of varieties, some more legitimate than others.
+
+ * After reviewing the plan, you can point to the places where the project has a lot of uncertainty that could go horribly wrong, and don't think that there's any way to measure that impact without doing the work.  For example:
+   * If you need to integrate with a third-party service that's still under development, you're going to spend an unknown amount of time testing with your counterparts and rewriting code as the target moves.
+   * If you need to optimize an algorithm to trim requests below a certain threshold, you can calculate a lower-bound for the run-time, but time spent actually trimming time can easily hit a point of diminishing returns.
+ * You're including overhead of work that you don't personally do, but is an unavoidable part of the project.  I'll talk about this more, later.
+ * You haven't the foggiest idea of what's involved in this project, so you picked a number out of a hat and threw in a fudge factor, just in case you're wrong; you're probably also planning to work late when the deadline approaches.  This is the situation described before, where developers tend to just find a compromise between sounding appealing and sounding possible.
+ * You don't trust the other party to uphold their end of your agreement, so you're just flat-out assuming that you're going to need to do everything multiple times.
+
+Uncertainty in the plan is almost always a legitimate reason to "pad" a schedule.  They're localized on the schedule and have specific justifications, so it's possible to isolate that part of the project.
+
+Overhead---design, management, testing, debugging---is also generally going to be legitimate, and probably even a good idea, as long as you understand the different roles involved in the project and which need to be part of your estimate.
+
+You see the "fudge factor" in cases where the developer doesn't understand how to build a real estimate.  You'll see people talk about "rules" of multiplying all initial guesses by two or three.  It's basically an admission of being far too optimistic as well as ignorance of scheduling, so it's probably best to steer clear, when you can.  It's a step away from "it'll be done when it's done."
+
+Finally, trust is, as they say, a two-way street.  In one direction, you have developers padding schedules because they believe that management or the customer is going to change the scope or even the *nature* of the project, meaning that someone will need to scrap or rework a fair amount of existing work.  In the other direction, management or customers might push to pad the schedule (or might budget for your schedule as if it was several times larger), because they don't trust the developer(s) to do the right work.  If you're adjusting the schedule because of a trust problem, you need to build trust, or your schedules are always going to leave someone looking foolish.
+
+Note, by the way, that Agile development processes have tried to take trust out of the process, by shifting the focus of planning to "sprints," when developers just try to get through as many tickets as possible, and then use that data point to predict what will happen during the next sprint.  In doing that, however, it also mostly eliminates the idea of rigorous estimates in favor of gut reactions.
+
+As I said about guessing above, there are contexts where guessing is fine, and Agile development processes are usually one of them.  Just be mindful about what you're doing and the risk that's introduced.
+
+## Process
+
+Now that we better understand what *not* to do and why we might care about estimates, let's talk about how to put a credible estimate together.  Improved estimates are important, because reliably getting work done on time helps to fix the trust issue discussed above.
+
+### Divide and Conquer
+
+That all said, the way I build my own estimates to increase the chances of it being correct is to recursively break tasks down with best-case and worst-case estimates, until the worst-case estimate is no more than a few hours long, since just about anybody is going to get that scale right, even if it's just a guess.
+
+That maximum-size time (of a few hours) is based on projects that are likely to take an on-one-hand number of worker-months, and so should probably be adjusted if that's not the likely scale.  Otherwise, you're mapping out hours on a twenty worker-year project or on a weekend hack, which is either a waste of time or futile.  To adjust, if we figure that three months has around five hundred work hours in them, you're talking about your smallest unit being a bit less than 1% of the guessed-at size of the whole project.
+
+Looking for the worst case keeps you honest and reminds you about all the little tasks you were going to just assume happened magically.  Don't skip that part.
+
+A plan might look something like the following excerpt.  Let's say that the project is a traditional blog.
+
+|Task Name|Best Case|Worst|Actual|Ratio|
+|---------|---------|-----|------|-----|
+|Index|👇2 h|👇5 h|||
+|👆 List Posts|30 m|1 h|||
+|👆 Paginate|1.5 h|4 h|||
+|Create Post|👇21 h|👇26 h|||
+|👆 Implement Default Editor (Scaffolding)|0 h|0 h|||
+|👆 Evaluate Rich-Text Editors|16 h|16 h|||
+|👆 Replace Default Editor with Rich Text|2 h|3 h|||
+|👆 Validate Input|2 h|4 h|||
+|👆 Preview Post|1 h|1 h|||
+|👆 Save Post|0 h|2 h|||
+|Edit Post|👇1 h|👇6 h|||
+|👆 Load Existing Post to Create Page|1 h|4 h|||
+|👆 Overwrite Existing Post on Save|0 h|2 h|||
+|Display Post|👇2 h|👇7 h|||
+|👆 Convert Internal Representation to HTML|0 h|1 h|||
+|👆 Insert CSS Classes into Post|1 h|4 h|||
+|👆 Show Post in Context|1 h|2 h|||
+|Add Comments|👇3.5 h|👇6 h|||
+|👆 Show Existing Comments for Post (No Threading)|1 h|1 h|||
+|👆 Create Comment Form on Post Page|2 h|4 h|||
+|👆 Save Comment Associated with Post|30 m|1 h|||
+
+I didn't bother to break up *Evaluate Rich-Text Editors*, because (a) this isn't a real project, (b) breaking it down would probably just mean listing the candidates, and (c) it's not out of the question to say "after I've spent two days on this, I'm just going to pick whatever I've seen that looks best."
+
+Anyway, this project outline gives us a fifty-hour prediction.  As tasks are completed, fill out the actual time spent in the fourth column, as honestly as possible.
+
+### Account for Overhead
+
+Next, take your development-time estimate and put together a 2:1:3 schedule of design/architecture time, development time, and quality assurance/debug time.  I forget where I got that guideline from, but it's basically fixed overhead that you don't want to think about up-front, and I've never seen anybody cheat that ratio.  You can push that work around---like having the development team use test-driven development---and an internal project can often afford to ship incomplete.  But as a sellable product, you need that design and test time, even though it feels wasteful.
+
+That is, for the blog plan described above that's planned to take fifty hours, the design time is going to be approximately one hundred hours, and testing/debugging time is going to come in at around one hundred fifty hours, for a total of three hundred worker-hours to make this a polished product.
+
+Well, that's not actually *entirely* true.  That sixteen-hour step to evaluate rich-text editors isn't a development task, even though a developer is going to do that work.  Instead, it's a design task that almost certainly incurs no QA time.  So as you get better at this, you might say that the real development schedule is thirty-four hours, with sixty-eight plus sixteen hours of design time, and a hundred and two hours of testing and debugging.
+
+### Feedback
+
+As you work, you then track your low-level estimates, in order to forecast how you should adjust them in the future.  Divide the worst-case estimates by the actual time spent.  Take the average of those ratios---that's not *quite* mathematically valid, but it's close enough---and use that final ratio to adjust the sub-task estimates on the next project.
+
+Note that this isn't a "fudge factor" like the above.  This is a recognition that you're still learning to get the small estimates right, so this is correcting for your bias.  As you go through more projects, you'll notice that the ratio gets close enough to one-to-one that you can stop correcting for bias.
+
+Don't stop tracking the bias, though.  If it starts drifting, you're going to want to know that.
+
+## Viability
+
+Yes, you're thinking that this is much more work for a proposal than "eh, sounds like a nine-month job to me," but it's work that makes it easy to get estimates *pretty* close to the actual work that'll be done, and also quickly see how any scope changes are going to impact the schedule.  That builds everybody's confidence, which is helpful.
+
+Because this gives you a good view on the cost of features, a process like this also helps argue for and against work based on the return on investment, which is more useful than just arguing that a project will be "good" for the product.
+
+*However*, like I hinted a couple of times, this process doesn't mesh well with Agile-style project planning, because Agile is built around the idea that long-term estimates are going to be wrong, so take all of this with a grain of salt for a modern office.  I suspect that there's probably a way to fit the two worldviews together, but I haven't gotten it to work, yet.
+
+* * *
+
+**Credits**:  The header image is [untitled](https://pxhere.com/en/photo/819794) by an unknown PxHere photographer, released under the terms of the [Creative Commons CC0 1.0 Universal Public Domain Dedication](https://creativecommons.org/publicdomain/zero/1.0/).