Mastering Programming (2016)
tidyfirst.substack.com
tidyfirst.substack.com
I can't say that I practice all or most of these habits, but the points about "calling your shots" and "concrete hypotheses" resonate. For example, when I add a debugging printf/log, I always ask myself, "will this output invalidate one or more hypotheses?" If not, then I need to rethink the problem.
The flow of 80/15/5 is what true seniority looks like in my opinion.
Do a lot of the heavy lifting on a goal, explore valuable (and sometimes promising but with a stretch) avenues around that goal and then be able to document and articulate in a way that another person can grow into it while you venture forth into the next challenge.
I will never accomplish perfection in coding. Much higher satisfaction in discovery and collaboration.
Come on, I know I'm about to hit 40, but slang can't be evolving that fast! How am I supposed to be keeping up with all the kids?
https://www.artofmanliness.com/character/knowledge-of-men/th...
Recommended: https://press.princeton.edu/books/paperback/9780691147437/cl...
At the time of these writing, only one comment was dead, and it was rude and content-free. The rest of its tree was arguing about Beck in general rather than the article, so everything’s working as intended IMO.
Programming advice from him and his cohorts (Ron Jeffries and Martin Fowler) should be regarded with several large grains of salt.
That said, the Wikipedia page neither supports nor refutes your assertion, and Fowler himself discusses C3’s failure here: https://martinfowler.com/bliki/C3.html
Fowler refers to notes that don’t seem to be in the Wikipedia entry any more: “In particular the entry in Wikipedia is misleading and incomplete, much of its comments seem to be based on a paper from a determined XP critic whose sources are unclear. Certainly its comments on performance are a misleading interpretation of material in my Refactoring book.”
Do you have any other links to this project? The fact that it went live and then reverted to the COBOL version is interesting.
I believe the characterization of C3 as a "failure" is because it wasn't able to deliver the goal (goal was paying 87000 people – it only reached about 9000), and was later discontinued for multiple reasons (some unrelated, like people leaving, the merger with Daimler). The claim that "XP was banned" there seems overblown, it seems it's just that "people at DaimlerChrysler stopped taking terms like Smalltalk, OOP and XP" (per link above).
To then use such a failure as a marquee project demonstrating the supposed "superiority" of XP is unabashed chutzpah.
Now, large IT projects generally fail. So, XP is not wholly to blame.
However, the proponents of XP pushed it as superior silver bullet to navigate both the political and technical waters of software projects. The fact that C3 was such a spectacular failure simply demonstrates that XP really wasn't any different than any other methodology being pushed by people with an agenda.
To me there are worse things in the story, though: they tried to make User Stories and even customer-driven tests and ended up burning out the only customer that was able to do it.
It's not only underwhelming compared to the silver bullet they were selling in conferences and books, but it required some unicorn customer that they couldn't replace.
For years I saw people trying to make poor customers and PMs write Cucumber tests and man...
This is still a legitimate concern today with the "product owner" role that a lot of popular Agile processes rely on. In effect the whole premise of having a PO embedded within the team as the authority on requirements that are expected to change at any time means the entire software development process is built around a single human point of failure.
I think I draw the line at asking them to produce user stories, to me that's already too much. Asking them to use Cucumber or BDD rituals is probably against the Geneva convention.
There really is no silver bullet to writing software. You gotta keep a short feedback with users, and not overwhelming them is important.
Practices like pair programming and TDD work on some instances, are absolutely terrible in others. The arrogance of the original XP folks was a hard core belief that they had found the silver bullet of software development, and then marketing it ruthlessly.
> To then use such a failure as a marquee project demonstrating the supposed "superiority" of XP is unabashed chutzpah.
> Now, large IT projects generally fail. So, XP is not wholly to blame.
One could argue that XP achieved a significantly better outcome than the typical project of that size. They didn't cause any big outages, and reached the end result of being cancelled and reverted much more quickly and cheaply than usual.
All these guys were in the "If it failed, it wasn't true XP." while they were cashing paychecks for promulgating it--Fowler included.
Unfortunately, all parties involved in the C3 project would rather that it be forgotten. As such, it seems that it is going down the memory hole even faster than most Internet things. :(
> So, I'm curious - does this represent a failure of XP? -- AnonymousCoward
> Sensitivity, certainly. But if the people who tell you what to do don't agree with the people who evaluate what you are doing, you're stuffed, XP or no XP. -- KentBeck
http://wiki.c2.com/?CthreeProjectTerminated
Between this and the Wikipedia article, it's not clear to me that the project failed due to XP practices.
Yet all these years later, the principles of OOP, and the companies built on them, outlived the politics that tried to squash them in the 90s.
Back then, OOP originally solved a very real problem--optimizing memory usage of bunches of objects that have mostly common behavior with just a few tweaks different from one another. It did pretty well at that at the expense of introducing some extraneous coupling and complexity.
And then memory got big and disk became SSD.
Now, programmers would rather burn extra memory, avoid pointer chasing (expensive on modern microprocessors), and ditch the extraneous coupling that introduces unnecessary complexity.
As it turns out, in many complex domains, you ARE going to need it, so you should factor that into your design sooner rather than later.
This is also why many consulting lead projects fail, because the developers do not understand the complexities of the domain.
Not everything is a CRUD website.
That's not to say the other 80% of requests should be ignored. But instead well documented and groomed in a backlog.
Fowler means it literally. He had examples published on Artima.com years ago where he gives examples of hard coding things left and right and adding better support “only when you absolutely need it”.
To be clear I am not arguing for big design up front. I am arguing to keep an eyeball on your roadmap, and that is not only OK to anticipate the future but maybe do some small amount of work to make the future work easier.
The fallacy of “You Ain’t Gonna Need It” is that you so very often do, and the developers down the road are cursing out the devs who ignored the future.
I also feel the same about "premature optimization," but that might just be due to my personality.
The "premature optimization" thing warned against making code hard to read/debug for the sake of performance in areas where performance is unlikely to ever be a concern. If you don't ship software, it is understandable this is isn't much of a problem.
Although I'm not sure how applicable that really is today anyway. The tools have changed dramatically. Often you want to make your code as readable/debuggable as possible as that also gives the best chance for the compiler to find the optimizations. These days, if you try to get fancy, you'll probably make the performance worse.
The point is that you aren't always implementing things that are unnecessary. You probably have a roadmap where you're pretty sure what you're going to be doing for the next few days and weeks and less sure as you look further ahead. Obviously you don't want to spend months building some over-engineered, over-architected monstrosity. But there are plenty of people out there who take YAGNI very literally and argue that you shouldn't implement anything you don't need right now. That's absurdly inefficient if you can guess with 80-90% accuracy what you're also going to need a month from now and you can save a lot of effort by implementing everything mostly right the first time and not repeatedly reworking code you've only just written over that time only to end up at the same place anyway.
YAGNI creates problems.
It doesn't say you should not consider future considerations in your design. In fact, it suggests that you should design your software to be as accommodating as possible, most notably by ensuring testing is core to your design to assist you when the time for change comes. The other poster you refer to and YAGNI seem to be in alignment.
The truth is in the middle, sometimes you need to design for the future and sometimes you don't. Often designing for the future just means making sure you haven't designed yourself into a corner rather than being able to fully deal with the future but that's a nuance most people miss.
Not as it seems to be usually defined, but I agree that programmers are bad for not sharing a common nomenclature. We can't even agree what something as simple as enums are. So, no doubt that there are camps who hold that perspective. enterprise_cog clearly comes from the "don't implement", not "don't design" definition, though.
it can also mean you don't need functionality you're not using, including implementations for those extension points.
John Carmack of Doom fame seems to share your definition, suggesting that attempts to plan architecture in advance will only come to bite you, but I'm not sure he is an XP subscriber and he certainly wasn't involved in C3.
It's a mis-interpretation and it's not a reasonable one either.
You need those extension points to keep your tests sane. They come naturally as part of the testing process.
It's even stranger when the deferral isn't even relevant.
Stranger still, the premise appears to be made up. I can find no mention of "Code that's hard to test in isolation is poorly designed" anywhere on the internet other than that blog post and another blog that cites DHH.
Beck's insight with TDD, over the testing that came before it, was really just that if you write the test first then you have certainty that the test fails. If you are writing tests for code that you have already written, there is no way to know if your test passes because your code is conformant or because there is a bug in your test.
But, whether your write your tests first or last, you do need extension points to keep your tests sane. Rails is no exception. In fact, I would argue Rails' success was directly related to it leaning into testing and it showing developers what extension points are most relevant for web applications as a result. Before Rails came along, throwing MySQL calls haphazardly into the middle of the HTML was the norm.
What's going to happen is that over time you'll eventually have the experience to understand what's being described here.
Because it turns out there's a lot of things that young people find weird that they later understand.
I figured.
> What's going to happen is that over time you'll eventually have the experience to understand what's being described here.
I've been around long enough to be aware of the surface level motivation – accepting the point without defensive dismissal would cause harm to your ego. I just don't get the appeal. Who cares about the ego? If you have no thoughts to share, why post anything? Surely if DHH wants to share his thoughts here, he can come here himself?
> Because it turns out there's a lot of things that young people find weird that they later understand.
Curiously, older people almost universally state that getting older means caring about the ego less and less. Maybe what you are trying to say here is that you are still too young to understand that? Fair enough.
or to quote a meme.
transparent poster is transparent.
It is recognized that you did answer the question. You said as a defence mechanism. That is understood. But the follow up is asking on deeper level: What needs to be defended against, exactly? What is that you think your ego going to do to you if you don't put up these defences?
seriously man, nothing you say matters anymore as you don't have the experience necessary to even begin to understand what I'm saying.
just stop.
The last coherent thought you had was an assertion that YAGNI may include not implementing extension points. But then DHH, while admittedly starting with a made up premise that made no sense, came along and obliterated that notion by the end, detailing how extension points – what he calls model, integration, and system – are necessary to keep tests sane.
And, since YANGI emphasizes testing, we can be assured it actually does include implementing integration points.
I don't get what the author means by this. Anyone wants to elaborate?
You do not further increase the complexity of this function by having one or two variables in the front, several if-elses in the middle not to mention a couple gotos.
You take these special cases and the most relevant logic away into yet another function, document it and hence ensure the changes to that 'special logic' do not mess up with the rest of that feature.
https://www.oreilly.com/library/view/tidy-first/978109815123...
Previous discussion:
How I came to write “Tidy First?” tl;dr it took 18 years
https://news.ycombinator.com/item?id=35246995
Tidy First?
and
For A new, non-expert, these suggestions might be too generic, too high level, broad. They wont grasp the point.
I might be, being miss-interpreted as dismissing this article.
They are definitely good points, and doesn't hurt to read them.
I think all the points are valid.
Maybe I was just contemplating how experts sometimes 'summarize' their knowledge, condense it, but in the process of trying to be succinct, becomes itself un-fathomable, generic.
Someone with a similar level of experience to the author may well have the right foundations to draw on such that a condensed expression of an idea resonates well. Others may only get a "seed pearl" to help shape how they view their past and future experiences. And some might be able to recognise that there is wisdom there, but not be able to relate it to their own understanding at all.
Without any relevant experience, it's just words devoid of much meaning.
As someone who is not an expert but tries to gain wisdom from past experiences, it helps me to see where my intuitions might have been right or wrong, even if I may not get the point right away.