null && void

Some articles on coding.

[preheateduser]

“Don’t do it at runtime. Do it at design time.” @BillSourour

[stoweboyd]

The sign of an organization becoming more creative is the move from processes to projects—projects are inherently creative acts.

Tim Brown, cited by Lisa Baird in Why High-Skilled Freelancers Are Leaving Corporate Life Behind (via obsessivecompulsive)

[preheateduser]

A Criticism of Scrum • Aaron Gray

Scrum has issues due to the maker's schedule, flow, observer effect, bikeshedding, and heavy overhead. It strains ties between management and developers.

[preheateduser]

processes that result in additional meetings, documents nobody reads, work that doesn’t directly support the organization’s purpose, or involve erecting obstacles to keep people on the “correct” path- these are bad processes.

http://thedailywtf.com/articles/processing-a-rant

[preheateduser]

Under Agile, technical debt piles up and is not addressed because the business people calling the shots will not see a problem until it’s far too late or, at least, too expensive to fix it. Moreover, individual engineers are rewarded or punished solely based on the completion, or not, of the current two-week “sprint”, meaning that no one looks out five “sprints” ahead. Agile is just one mindless, near-sighted “sprint” after another: no progress, no improvement, just ticket after ticket.

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

[preheateduser]

“Agile” is a culture of terminal juniority [...]. Agile has no exit strategy. There’s no “We won’t have to do this once we achieve ” clause. It’s designed to be there forever: the “user stories” and business-driven engineering and endless status meetings will never go away. Architecture and R&D and product development aren’t part of the programmer’s job, because those things don’t fit into atomized “user stories” or two-week sprints. [...] Aside from a move into management, there is the option of becoming a “Scrum master” responsible for imposing this stuff on the young’uns: a bullshit pseudo-management role without power. The only way to get off a Scrum team and away from living under toxic micromanagement is to burrow further into the beast and impose the toxic micromanagement on other people. What “Agile” and Scrum say to me is that older, senior programmers are viewed as so inessential that they can be ignored, as if programming is a childish thing to be put away before age 35.

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

[preheateduser]

Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

This article nails it in so many places. More quotes coming up.

[preheateduser]

Getting rid of fixed iterations was by far the strongest thing we did. We used to run two week sprints which broke down roughly like this : Days 1 and 2 : Fixing the stuff we had hacked to make it look like it all worked in the last review. Days 3 and 4 : Planning. Sitting in a room *determined* to plan every last detail of the next two week’s work. Three people talking all the time, three people sitting quietly in the corner, two people rocking slowly back and forth contemplating suicide. Days 5 to 8 : Yay !! Coding, testing, working, producing good stuff, doing what we were employed for. WOO !! However, we did need to also work out a way to crow-bar defects through the system when they weren’t actually attached to a story, and they weren’t new work . . . they just didn’t fit – perhaps we could have a bug-fix Sprint next time, maybe we should exclude them from the burn-down as they aren’t new work, perhaps we could just fix them in over-time etc etc ? Day 9 : Start hacking unfinished stuff to make it look good for the review. Day 10 : Finish the uncomfortable hacking, arrange the mirrors, start the smoke machines. Review at 2PM. By 4PM everyone feels down that they haven’t been able to focus on actually getting good stuff done, but hey, it’s the weekend now, byeeeeeeeee. Then rinse and repeat with a constant background of noise from management’s morbid interest in the shape of the graph and the particular curve of the burn-down chart and exactly when that line was going to get steeper. Now, I am explicitly and very loudly *NOT* blaming Scrum for this any more than I blame geography when I can’t find my car keys, but the framework/process gave us an excuse to focus on the wrong things and it really helped us to fool ourselves that we were being successful because we were following the process well even though we weren’t producing any product.

http://mhsutton.me/scrum-designed-misuse/#comment-3194

[preheateduser]

The following practices are particularly subject of my ire, particularly because teams too easily fall into the trap of believing that these are the “point” of Agile: - Tasks - Task Estimations (often in hours) - Individual capacity planning - Iteration commitments - Iteration burn-downs - Daily Stand-ups Is your individual and team value defined by how well you perform these activities? Do you invest significant time in these practices? Are you getting value out of them? Does the team feel they have the empowerment to stop doing any of these? To be fair: the real issue is how Scrum is (mis)applied, rather than Scrum itself. However, how many times does Scrum have to be misapplied before we treat it as a fault in the framework itself?

https://medium.com/@onleadership/scrum-the-best-micromanagement-tool-around-d190f6291b2f

[preheateduser]

Let’s look again at the four values:    Individuals and Interactions over Processes and Tools    Working Software over Comprehensive Documentation    Customer Collaboration over Contract Negotiation, and    Responding to Change over Following a Plan The phrases on the left represent an ideal—given the choice between left and right, those who develop software with agility will favor the left. Now look at the consultants and vendors who say they’ll get you started with “Agile.” Ask yourself where they are positioned on the left-right axis. My guess is that you’ll find them process and tool heavy, with many suggested work products (consultant-speak for documents to keep managers happy) and considerably more planning than the contents of a whiteboard and some sticky notes.

http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

[notational]

Every programmer occasionally, when nobody’s home, turns off the lights, pours a glass of scotch, puts on some light German electronica, and opens up a file on their computer. It’s a different file for every programmer. Sometimes they wrote it, sometimes they found it and knew they had to save it. They read over the lines, and weep at their beauty, then the tears turn bitter as they remember the rest of the files and the inevitable collapse of all that is good and true in the world. This file is Good Code. It has sensible and consistent names for functions and variables. It’s concise. It doesn’t do anything obviously stupid. It has never had to live in the wild, or answer to a sales team. It does exactly one, mundane, specific thing, and it does it well. It was written by a single person, and never touched by another. It reads like poetry written by someone over thirty.

Programming Isn’t Manual Labor, But It Still Sucks

By Peter Welch

(via notational)

[preheateduser]

Let’s stick to the title, the core of his message: We need to focus on code - because only that’s delivering value. And we need integrate feedback into our work much more seriously - because only then we know if we’re actually heading in the right direction with our code. Forget about hype, buzzwords, and any elaborate belief system like “Agile” or “Scrum” etc. Yes, like the Buddhists are saying: “If you meet the Buddha on a road, kill him.” We need to kill our Buddhas, the gurus, the dogmas. Let’s do away with cargo cults. Instead focus on the essential: production code. And get as much feedback as possible. Truely become a closed system on many levels of your daily practice and your organization.

[preheateduser]

If you really, really buy this - it's about code and about feedback -, then you also have to buy the implication: Coding has to progress in tiny steps. Because only tiny steps can get you frequent feedback. If you hack away for an hour or a day without feedback, then you're coding pretty much in the dark. Truely frequent feedback is not more than a couple of minutes away.

[preheateduser]

When Copy and Paste becomes a Problem

“When to copy and paste, and how much of a problem it will become over time, depends on a few important factors. First, the quality of what you are copying – how understandable the code is, how stable it is, how many bugs it has in it. You don’t want to start off by inheriting somebody else’s problems. How many copies have been made.  A common rule of thumb from Fowler and Beck`s Refactoring book is “three strikes and you refactor”. This rule comes from recognizing that by making a copy of something that is already working and changing the copy, you’ve created a small maintenance problem. It may not be clear what this maintenance problem is yet or how best to clean it up, because only two cases are not always enough to understand what is common and what is special. But the more copies that you make, the more of a maintenance problem that you create – the cost of making changes and fixes to multiple copies, and the risk of missing making a change or fix to all of the copies increases. By the time that you make a third copy, you should be able to see patterns – what’s common between the code, and what isn’t. And if you have to do something in three similar but different ways, there is a good chance that there will be a fourth implementation, and a fifth. By the third time, it’s worthwhile to go back and restructure the code and come up with a more general-purpose solution.“

[preheateduser]

A rational alternative for “agile”.

[preheateduser]

[...] the "15 minute rule." That is, if you're stuck on a problem, take a solid 15 minutes to bash your brain against it in whatever manner you see fit. However, if you still don't have an answer after 15 minutes, you must ask someone.

[preheateduser]

Why developers are like artists

Code is clay

I often feel like I'm claying when I'm coding