[Paraphrasing] There are lots of things we don’t know that we don’t know about [the project we were working on]. Agile is how we optimize our process for learning those things. – Ward Cunningham

One of the things that really changed how I thought about building software was learning about the Dunning-Kruger Effect. I didn’t know that’s what I was called, mind you, but I certainly had witnessed it and once it was explained, it made perfect sense. What is the Dunning-Kruger effect?

“people reach erroneous conclusions and make unfortunate choices but their incompetence robs them of the metacognitive ability to realize it.”  - http://en.wikipedia.org/wiki/Dunning-kruger_effect

What does that have to do with Agile? Well, some of the seeds for Agile, at least from Kent Beck and Ward Cunningham’s influence came from the days when those two guys shared a lab and were partners in R&D at Tektronix. I’ve written about this before, but basically, their job was to come up with, every set period of time, some idea that Tektronix should pay a team of guys to develop out into a product or tool. So, KB and WC would come into work every morning and one of them would propose an idea and they would spend the morning trying to hack the idea into working software. If it wasn’t working, they’d go back to working on whatever was the last best idea, and then at the end of the time period, they always had something that worked that they could turn over as an idea. This is where some of the seeds of TDD, iteration, and other ideas that are now staples of Agile came from.

But why would you do that? Why would you essentially start over every morning? Well, as it turns out, humans are really bad at knowing what they don’t know. So why not come up with an idea and just work on that idea until you had something? Let’s explore that. . .

BDUF is for those that don’t understand the Dunning-Kruger Effect

I don’t feel like this is a very controversial topic (that might also be the other end of the K-D Effect) because I think this one has already won out. It certainly has in the ruby community. I’ll go ahead an explain it though. BDUF stands for “Big Design Up Front” and most non-enterprisy, non-corporate software teams know, you can’t design all of your code before you write your code. And the agilists out there will even say that the only way to write truly simple clean code is to write a test first. I hope this isn’t a big shock to anyone. If we examine why this is true, we pretty quickly get to a point where you say “we don’t know enough about the code to design the code without first writing some code”. In other words, we don’t know what we don’t know about the code yet, we have to learn what we don’t know and adapt our application architecture as we learn. I guess if you get a CS degree, you’ll run up against a whole set of folks that don’t believe this, but I’ll go out on a limb and say that most of those folks also don’t write much software. Anyway, suffice to say, we’ve got a whole set of practices, red-green-refactor, continuous integration and deployment, to optimize against doing BDUF (among other things, surely).

Specification Documents are for those that don’t understand the Dunning-Kruger Effect

Another example (I think more important and less widely accepted, and the real reason I wrote this post) of the optimization for all the “things you don’t know that you don’t know” in Agile is that we don’t write spec docs. We don’t start out a project with a giant document that spells out everything we’re going to build. That’s not to say no one knows what we’re building, or has a vision of what it looks like when it’s done, au-con-trair, that’s definite a recipe for disaster (and, I think, most people’s biggest fear that haven’t participated in an Agile project). We spend the time to write all of this down in whatever format we would need to give it to a developer and walk away. Why? Well it’s that damn Dunning-Kruger effect. You *can’t* actually write a good spec, and not only that, those that don’t know this are the ones that precisely think it’s possible. No matter how many lines of code you’ve written, or UI’s you’ve designed, or businesses you’ve started, you will never know enough about what you don’t know to write a document that will cover every edge case, angle, possibility, challenge and decision that has to be made to successfully create quality software.

I hear this lot when I tell people this: “But you can change your spec” or “Good specs allow for learning”. I’m sure you can and I’m sure they do. Change and learning is precisely what agile is all about and not just embracing change, but optimizing for it. You’re *always* going to change that spec. Every project I’ve ever been on, at one point or another, something was too hard or expensive to be worth it and we’ve always changed what we’re going to do. Most of the time, this something was a surprise. It wasn’t what we thought would be hard or even something we thought we needed to do! I’ll even go further to say that some of the more successful projects I’ve been on, not only did we optimize for learning things early, we optimized for being able to change things easily.

The problem with writing a spec and then changing it, however, is that usually this renders part of the spec useless, or worse yet, it renders useless some “real work” you have already done. There’s a million quips and anecdotes people use for this, “Fail fast. . .”,  ”If you’re not embarrassed when you launch your project, you waited too long”, etc. The reason people say these things is precisely because they’ve experienced the Dunning-Kruger effect. They’ve written a spec or built software thinking they had their bases covered, that they knew things, but they didn’t end up knowing everything and not all of what they thought they knew ended up being true. And many of these people have come to the conclusion that if they would have done less planning, and got to implementing even faster, they would have learned important information that they didn’t know they didn’t know earlier and saved themselves work. XP is about optimizing for this in a technical setting, “The Lean Startup” is about optimizing for this in a marketing and product development setting.

The interesting thing here is that I’m cooking the meat (skirt steak) directly on the charcoal. No grill, no foil, no pan, just meat directly to red hot glowing chunk charcoal. This develops and intensely smokey flavor in the meat. You can see there are large areas of “burnt” meat, but it’s not actually burnt, it’s just caramelized and full of flavor. I’ve never had skirt steak so tasty, very caveman, in a good way.

When the steak was done (3 minutes per side, don’t even think about touching it while it cooks, and then let it rest 15 minutes), I put a cast iron skillet directly on to the coals and let it get smoking hot. I put the standard white onion and green/red pepper that I drizzled with a little olive oil and salt and pepper. The skillet was so hot the veggies instantly started to caramelize and you have to stir them almost constantly or you will get a little burning. Cooking the veggies takes less than 5 minutes (definately don’t over cook them) and the flavor is also amazing. If you ever wonder why veggies take so much better in good chinese food, it’s because they cook them super super hot like this. As a side note, if you want to make really great stir fry and don’t have a really nice gas wok stove, this is actually a good way to do it.

Enjoy with a Cascadian Black Ale and plenty of guacamole, preferably on your beautiful patio with your bride.

#railsconf

Anyway, about 6-8 months ago, I looked into Rubymine. I knew Pivotal Labs used Jetbrain’s IdeaJ IDE with a ruby plugin for a long time, so I thought a Rails specific version might be pretty interesting. I’ve used it full time, every day, since I tried it out and I really love it. I find it super productive and it has all the tools that I use my development flow all in one app.

First of all, I’ll state for the record that Rubymine is not a text editor. I still use Textmate every day. You won’t open up random files in Rubymine to edit them. Second, I don’t edit CSS in Rubymine. I use CSSEdit from MacRabbit. So I have no idea how it does with CSS. I also don’t really use Rubymine on my laptop. Most of the win I get from Rubymine is that it’s SUPER efficient

Here’s what my Rubymine setup looks like:

Things to note:

1. Close the file browser and use split windows. Get rid of the toolbar, you don’t need that.
2. Open up the Run tab on the bottom and move that out to a different window. Then fire up a Rails console and it will be out in that window also. Move this window over to your other monitor (stop reading if you don’t have one, you’re dead to me) and make the editor full screen.
3. If you open up the preferences go to Editor => Editor Tabs and check “Show Tabs in a single row”
4. I’ll leave this up to the reader, but figuring out how to get Spork up and running is all kinds of win.
5. I use a modified version of the Mavenlink theme. I’m using Menlo in 14pt and 1.4 line spacing for my font.
6. I have loads of my own tab expansions, which are called Live Templates in Rubymine. (‘%=’ + tab outputs <%=  %>). The default ones are lacking, I should package some of mine up, but since I created tons of my own in Textmate, most won’t make sense to you. Suffice to say, I don’t like haml, I like erb + live templates. That’s how many I have.

My favorite Rubymine features:

1. Command + B with your cursor on any Ruby/Rails method will take you to where that method is defined. This is way better than any documentation because I CAN READ RUBY CODE. I have been known to write out code just to command+b it and remember if it’s the method I want.
2. Control + H on any Ruby/Rails method shows you inline documentation. Win.
3. Control + Spacebar in .feature files will let you ‘live complete’ Cucumber scenarios you’ve already written, including the substitution regex in them. If you don’t understand how much win this is, I can’t help you.
4. Refactor => Rename is fucking awesome. Rubymine 2.0.2 will even rename “some_message” in SomeModel.should_receive(:some_message). Rubymine is pretty smart about this stuff, and when it isn’t they’ll fix it (I requested the should_receive stuff and they made it happen).
5. Item #4 reminds me of my favorite feature over all. Jetbrains is actively developing Rubymine, so if you have a feature request, or you find a bug, or something annoys you, THEY WILL FIX IT. I don’t know about you, but I am morally against Textmate at this point because I don’t think the creator is working on it anymore. He won’t open source it though, because it still makes him money (and I’ve heard the internals are a nightmare). Rubymine’s developers use Cucumber to test it, and I think I even heard they use Rubymine to build Rubymine. They are committed to the product, to making it better, and to listening to the Rails community. I’m willing to bet, if the community were to put it’s weight behind it, we’d see even greater support.

My gripes:

1. Rubymine is buggy. It just is. But I’m over it. They’ll fix them. If you find a bug in Textmate (like I don’t know, search), you’re never going to see a fix. Never.
2. Rubymine will sometimes need to re-index your project. This usually isn’t convenient, but if you want all those cool features I just spoke about, and search that’s fast, and lots of the other things that make Rubymine awesome, then suck it up and take it. You need a break anyway.
3. Rubymine can’t keep up with Yehuda. That’s just the facts. Rubymine has to know alot about Rails, Gems, Bundler, Cucumber, etc and changes in all those underlying libraries will sometimes make it painful to upgrade them and have Rubymine’s awesome features. That’s just life in the fast paced world. Having said that, Rubymine does a GREAT job trying to keep up. For example, it already supports bundler 0.7. Rubymine 2.0.2 will support bundler 0.8 and most of Rails 3.0. It’s got support for haml and sass and spork and lots of cutting edge stuff. And again, they are actively keeping it up to date (can I mention that enough?!?).
4. Rubymine is a resource hog, but then again, it’s not like I have a lot of other stuff going on my laptop, so it’s not usually a big deal. Also, I’m sure others see this more as I have a SSD drive and it makes this not a big deal.

Chris Bailey prompted me to write this post, and he’s got some stuff on his post about Rubymine I’d like to clear up:

Doesn’t work (well) with MacOS X Spaces – prevents switching to another space when you select another app

I have no idea if this is true or not. I don’t use Spaces, sorry. However, I will say, I don’t switch away from the app much through out the day. Also, submit a bug! They’ll fix it if they can.

File tabs:

• They go to multiple rows too easily.
• They just don’t look right/good.  I’m not sure if it’s because they’re non-native tabs or what.
• I understand, but don’t like how the rows swap when you change to a different tabs.  You lose track of where a file is in the tabs.

I address this above, but I’ll re-iterate. Making tabs into a single line in the preferences will make Rubymine majorly better.

Find in project is nowhere near as fast, or presented as usefully as Ack in Project for TextMate.  It does provide more options, such as filtering files by directory or type and so on, but the speed is generally far more important.

This is puzzling because I have found find to be very fast. And yes, it has MASSIVELY more and better options than Textmate. I haven’t used Ack in project much, so I can’t comment.

Also seems to crash enough that it bothers me.  I can tolerate an occasional crash, although with TextMate I’ve run it for weeks on end with no crash, using it constantly.  I’ve had several either hangs or crashes with RubyMine in the short couple weeks I’ve been trying it out.

I know Pat Maddox has seen his share of crashes. I never see crashes. I don’t know why, but Rubymine is actually more stable for me than Textmate. Even on big projects.

The refactoring bits were just ok.  This is a really hard feature in general though.  Simple refactorings I used, like renaming a method worked fine.  But, changing the name of a model class did about 1/4 of the work needed and was questionable as to whether it was an advantage over just doing it all myself.  It got all the obvious, low-hanging fruit, but it seemed to completely ignore Rails helpers and views.  It misses a bunch of things that I’m not surprised at of course, such as table names in SQL conditions (e.g. in named_scopes), model name used anywhere in JavaScript or CSS (which isn’t uncommon in Rails code), and then the one that I’d like to see it do a better job on, but that is hard of course is on associations.  So, in my application, I was refactoring our “Deal” model to be “HotelDeal”.  We have a “Hotel” model and it has_many deals.  Thus in the code you’d routinely see things like “hotel.deals” to reference that association.  It didn’t handle any of those.  Not surprising, but starts to devalue the refactoring feature.

I’d submit bugs for these things. Also, I don’t know what version Chris was using, but this stuff has been getting better with recent versions.

At the end of the day, there are probably specialized tools that do each of the things that Rubymine does just a little bit better. GitX is definitely a better git/diff reader. Textmate is better for just plain editing files. CSSEdit is better for CSS. Terminal is a better shell. But for me, being able to have all of these things in one tool, and the few Rails specific things that Rubymine does provide, make up for the small things it doesn’t get right. If you give Rubymine 10 minutes, I’m sure you’ll always go back to what you were using before. However I gave Rubymine a month, and now that it’s 8-9 months later, I wouldn’t ever consider going back to Textmate.

I first started using Bundler 0.7.6 in December ’09 in a Rails 2.3.5 project. We also use Bundler (not sure what version we started with) in our main Rails 2.3.x app that powers www.Goldstar.com. In the 3+ months that we have been using bundler, it has, by far, been the largest pain point and time sink of any part of our toolset to the point that today, I proclaimed on twitter, than in it’s current state, I can’t recommend Rails 3.0 to anyone starting or upgrading a product.

Now, if you know me, you know that this is pretty out-of-left-field. I’m a HUGE Rails evangelist. And I truly believe that it’s right for many projects in all kinds of scenarios.

Anyway, on to the fail. . .

Bundler 0.7.x had lots of issues, too numerous to count. However, it did have the option to pass a yaml file to it via –build-options that would allow you to pass a few arguments into the various gems it needed to build. This was good enough for us, and we followed the convention we use with database.yml to have all the correct options in the various environments we use to dev/deploy our rails apps.

Builder 0.8 soon followed suit (I believe in January) and messed us up by changing the path inside the bundler folder that all the gems where kept at to be name-spaced to what version of ruby you were using. I’m not sure what this was meant to fix, but it broke a few things for us and it broke Rubymine (my personal editor of choice). But hey, we upgraded.

I’m going to leave out all the pain that was causes by upgrading to 0.8 and just say that we are currently using Bundler 0.8 in dev and production, except that a bug, where older version of already cached gems won’t upgrade unless you rm -rf the bundler directory (json-pure-1.2.2 to json-pure-1.2.4 fwiw) is breaking our deploys to production. This means that every deploy to production, we can’t be sure the bug isn’t going to break it, so we must rebuild every gem in the app (of which there are MANY) every time we deploy. This just isn’t going to work for us.

Now, we’d like to move to Bundler 0.9 because it promises to fix our issue (bundle install correctly updates gems as required). However, –build-options has been removed from 0.9. Because –build-options was removed, bundler has moved to a don’t-vendor-some-of-your-gems solution where it will use gems from the system if they aren’t in the bundle. This allows you to pass different incantations to `gem install` for different gems (mysql, pg, etc) and it will use those already built gems when you later do `bundle install`. But that means we’re back to managing gem installs on all of our different systems in different ways, which was one of the few things that Bundler did significantly better than config.gem!

Our systems developer, Steven Baker, is currently working on re-implimenting a solution to the –build-options issue, which he first ran by “Carlhuda” in hopes that they might include it and we’re not going down a road that will just end in us playing by ourselves and having to re-impliment our Gemfile or build_options.yml file for whatever solution is, but this brings me to my point:

Rails 3.0, because it relies on Bundler, is not in anyway stable/useable/suggested unless you want to pretty continuously fix/re-impliment/cry yourself to sleep because of Bundler. Carl L. has posted a roadmap which shows at least 2 more revisions as well as closing 20+ currently open issues. I have no idea what the issue velocity is on the project, but to me, it looks like it’s in the months and not days or weeks before Bundler is going to be stable. And, as with every version before it, there have been major downsides to the implementation, that have forced pretty major breaking changes. In other words, every version of bundler is a new experiment (not to mention the various gem management techniques that merb used which were also a source of headaches), and I have little confidence that just slapping 0.9 or 0.10 is going to change that.

Bottom line: A significant piece of Rails 3 is still in the “spike” phase, and shows little to no promise that it will become solid enough to trust for _months_.

Please skip the “Patches are accepted” (we’re working on one kthxbye) and “Why are you even using bundler?” (troll). I’m not here to indict or blame anyone, just to report our experience and clarify why I’ve lost significant confidence in Rails because numerous people have asked.

Sidenote: I’m putting this at the bottom, because it’s secondary to the point of the post, but why, precisely, do we *have* to use Bundler to make Rails 3 work? Who made this decision? If it was the same people that wrote Bundler, doesn’t anyone see a problem with that (NIH)? I’m assuming there were discussions in the rails-high-council private campfire room at some point, but obviously us peons aren’t privy to those. Config.gem wasn’t the easiest thing to use, but I’ve successfully used it for close to a year with very few issues and had it’s eccentricities worked out pretty well. To have it completely removed from Rails 3, and replaced by an experiment, seems a bit premature.

I can’t, in any way, tell which of those lines belong to which label. They both look green to me.

1. Writing code well in a way that you could keep adding developers and they could each increase productivity linearly.
2. Writing code that will work for increasingly larger sites.
3. Writing code that is maintainable, testable, and extendable.

I know others have thought about this, some people call it “best practices”, some people call it frameworks, Yahoo even went as far as to create the YUI family of libraries. I think deep down, most people were trying to think about how to “scale” whatever it was they were doing.  This entry is the first in a series of writing jQuery code that “scales”.

Another thing I probably need to address before we get started is “Shu”. It comes from the Japanese phrase “Shuhari“, which I learned from Alistair Cockburn and is common in the Agile circles, and “describes the stages of learning to mastery”. Once you’re aware that there are certain levels of mastery of something, you start asking yourself which level you’re at and what level others are.

JQuery is awesome, and I love it. For along time, I treated javascript as a 2nd class citizen, but I’ve recently been really digging into it and making it “scaleable”.

In Dan Cederholm’s recent book, he introduces some jQuery that I’m lumping into the “Shu” box (ba-da ching!).

$(document).ready(function(){
$("#loc-adv a").click(function(){
$("#map").slideToggle("slow");
return false;
});
});

Now don’t get me wrong, this code is perfectly acceptable, especially for the situation it’s presented in (a small, static site, built by 1-2 developers). I’m all for not complicating things if they don’t need to be. This code is the simplest thing that could possibly work, and that’s awesome. However, we’re talking about scaling javascript up to larger sites, more developers, and maintainable in legacy applications, and there are some things about this code which don’t make it very scaleable.

First, it’s not really re-useable. Sure, you could include it in any page that has the `#loc-adv` a link and a map, and it’s going to work, but what if  you needed multiple maps in one page or had multiple links. All of a sudden, you’re going to need to repeat yourself, and we don’t do that.

Second, if you put this right in your page, as it’s presented in the book, you can’t use it on other pages without repeating yourself. Maintaining this code could be painful if you put it in more than one page.

Third, the only way this code is going to fire is if you click the link. There’s no way to call it from other code, or test it, and you’ll have to attach it to multiple elements if you add another link or some other element that needs to reveal the map.

What if you want to link to the page with the map open? This code won’t account for that.

I’m not going to address all these issues in this post. I’m going to leave that up for the “Ha” and “Ri” posts. Look for them in a couple days.

I was reminded of this when I checked out Google Wave recently. When I signed in, I had 1 contact: the person that invited me. Their presence was shown by either a red or a green dot. Not an icon, but a dot. Not a large dot, a small dot.

So here’s the problem: I have no clue, litterally none, whether that person is there or not, because I can’t tell if that’s red or if that’s green.

Now, I’ve had this conversation so many times I can tell you what you’re thinking. You want to ask me, “What color is it?”. I can’t tell you. They are either green or red, but I don’t know. In fact, I can’t even tell if they are the same or different colors. Both of the dots look green, unless I think they are red, then they look red. I know, it doesn’t make sense. I literally can’t tell what color they are. I’m actually red-green-brown color blind, so they could be brown and I’d have no idea. All I know is: Google, you’re doing it wrong.

Facebook on the other hand, did it mostly ok. The blue moon is great for away. A green dot for available? That’s just lazy (and 2 different metaphors).

Update:

Here’s an example of a red/green combo I can differentiate and one I can’t.

Remember when Jason Calacanis said he’d pay $250k to be a “suggested” follow and TechCrunch said this was how twitter would make money:

If other companies feel the same way, sellingthese slots could be a lucrative side business for Twitter. At $120,000 a pop, 20 slots would generate $2.4 million in revenues the first year.

And then there was Sam Gustin on Wired.com on 8/04/08 lamenting that waiting to make money was going to hurt them:

Stone’s hesitance to “monetize” Twitter echoes that of other major Web 2.0 companies, such asFacebook and YouTube, whose founders have said they’d build their audience first and find revenue streams later. But those giants have shown that converting eyeballs into money hasn’t exactly been easy; Facebook has yet to start generating meaningful profit, and Google has said on a number of occasions that it has yet to find the right business model for monetizing YouTube’s considerable traffic. Twitter, despite some plans Stone has up his sleeve, may very well find itself in the same position.

Remember when Fred Wilson said that Twitter would make money the same way Facebook would:

I think you have to look no farther than facebook to see where all of this is headed. They are the Google of social media. They are going to figure it out When they do something that works (becoming a platform for third party apps) others will follow in their wake. When they make a mistake (beacon version one) others will learn from that mistake. I am not saying that twitter is going to monetize exactly the way facebook is going, but I think that’s a good place to look for inspiration right now.

Remember when Bernard Lunn (10/15/2008) was complaining because Twitter wouldn’t tell us how they planned to make money? Oh noes:

Twitter is the poster child for the ‘scale first, don’t even think about revenue at launch, monetize much, much later’ model of startup. In the current climate, ventures like that probably won’t get funded. Which is a shame. Twitter is addictive and fun and even occasionally useful. If anybody can pull this business model off, it will be Twitter. It has scale, seem to be moving mainstream and they’ve even fixed their reliability issues.

But Twitter won’t survive if it doesn’t find a great revenue model. This matters to all of us.

So, what now that they know how they are going to make monies?

It turns out it’s really hard to know what people want before you make it. There are certainly ways to mitigate it, user observation testing, paper prototyping, but sometimes these things end up taking more time than just doing the simplest thing that could possibly work. In the end, you just need to build it, get it out there and see if anyone cares.

Well, the other side of this coin is that it’s also really hard to limit yourself to doing the simplest thing that could possibly work. You have to say “no” to many things and many people, including yourself, and people just aren’t good at that. No one wants to be the guy that always “puts down others ideas”.

Helvetification

I’m very happy to be seeing a new trend in web apps, minimalism. I can only hope, that it continues to pervade all corners of software, both web based and desktop based. The tip of the spear seems to be the “helvetification” of popular apps. Some examples:

• helvetireader
• helvetical
• helvetwitter
• helvetimail

So what is so interesting about some new skins for some web apps? Is it just that I really like Helvetica? Well, I do like Helvetica, but the really interesting thing about these skins is not that they change the fonts and colors, it’s that they actually hide or remove significant parts of the apps. I’ve been using Helvetireader for probably over a year now, and I can’t stand to use google reader without it. I *hate* what GReader has become. It’s got tons of stuff I could care less about (probably say, 80% of it’s functionality). Starred Items? I use delicious. Trends? Really? And my favorite “Browse for stuff”. Uh, what? Isn’t that what using the internet is? What if Google Reader was the simplest thing that could possibly work? I think it would look like Helvetireader.

But Wait, There’s more!

So how does a couple skins for a couple web apps me that this is a trend? Well my friends, I didn’t think it did until I saw this:

What is this? It looks like facebook, but they’ve gotten rid of all the crap I don’t care about. Lite.Facebook.com is supposed to be a version for “low bandwidth users”, but boy it sure does look like a minimal version of Facebook to me, and I like it. Compare it to say, myspace, and we’re talking Donald Judd levels of minimalism. And have you seen an Amazon Kindle? What about Readability from Arc90 (which happens to be really popular)? All of a sudden, we’re starting to get into trend categories, and I haven’t even mentioned how minimalism is the entire strategy of Apple, 37Signals, Twitter, and Tumblr.

But Features Are Good!

Well, features can be good, but they can also be terrible. Recently, an interesting sounding website called “Gist” launched. What does Gist do? “Gist is designed to help the professional email user who often opens up their inbox only to feel like it’s helplessly out of control” (via ReadWriteWeb).  When I think of designing a site that is supposed to “take control” of something which is in chaos, I think of clean, minimal, organization. I would think that this tool would help me get to inbox zero, where there’s nothing in my email inbox but whitespace and the freedom to actually get my work done. So when I see screen shots like the one to the right, I can’t but help to think, “Is this really the simplest thing that could possibly work?”  This is a site that’s coming out of beta today. Not something that has been around for a decade. How would anyone know where to look, or what any of those boxes do?

Minimalism != the simplest thing that could possibly work

I could give you a bunch of definitions from famous artists and architects about minimalism, but I’m going to just say that minimalism isn’t the simplest thing that could possibly work, it’s when you optimize tsttcpw. The important point here is that it’s important here is that if you do more than tsttcpw, then you’re much less likely to rip out the parts that no one cares about. And I hope it’s apparent that, people want you to remove this crap. They don’t want more features, they want better experiences. They want that 20% of your application to be 100% of your focus, and they want the 20% to get better, not slowly become 18%, then 12%, then 10% because you keep adding crap they don’t care about. Minimalism, whether it’s in design, or any thing else, is taking that 20% and making it 100%.