Category Archives: Philosophy

The Agile Uprising

Leave a reply

We were discussing (on a mailing list) the Egyptian uprising and the interest in watching to see who/what stepped in to fill the vacuum of an apparent “leaderless” bit of unrest. Will there be freedom and democracy? Or yet another autocracy? I think there are some parallels to our software world.

Sometimes I wonder if some folks just — subconsciously maybe? — like to be told what to do. After all, it is easier to follow a prescriptive process that you are told will result in the desired goal, than being asked to achieve a goal on your own.

In 2001, the “Agile Manifesto” asked folks to achieve a goal, largely on their own. While there are plenty of agile practices that one can adopt as individuals and teams, there was no glaring “Rational Unified Process CD” with all the process, roles and diagrams that you could ever want to hide behind. There was no venerated “Waterfall Process” that allowed entire silos of functional teams to work on their own with little linkage to being effective at ultimately meeting the goal (until it is too late). There was no marketing-driven organization crying out for the need to be more agile. Hence, it has taken nearly a decade for Agile to become mainstream.

In 2001, Agile was just kind of thrown out there, fanning the flames of freedom for millions of software developers. For a long time, there was no real concerted effort to coalesce a new form of software development and spread it among the unwashed masses.

There didn’t need to be, or so I thought. Agile urges each individual to (using a US football metaphor) “throw the BS flag” whenever there is a need. Agile asks each individual and team to be craftsmen and do their best to achieve the client’s goal.

Agile throws off the shackles of command-and-control and bureaucratic absurdity. Agile works best from the bottom up, being “pulled” in the proper direction as we attempt to satisfy the needs of the clients — not force dictates down their throat. Agile expects and demands the best from individuals.

However, with great freedom comes great responsibility. Being agile is simple, but not easy.

I suppose some dominant command-and-control, bureaucracies were threatened by Agile uprisings, and kept the practices suppressed, driving some teams “underground.”

In the past few years, however, our community has seen a major embracing of Scrum by small and big companies alike. Maybe Scrum looks enough like routine Project Management that bureaucracies can be easily led to buy into this “agile” stuff.

So, maybe the Scrum Alliance did step in to fill that leadership vacuum after all?

Simple != Easy

2 Replies

In a nice, vintage post from the oh-so-wise Ron Jeffries,  as I saw this heading:

“It couldn’t be that easy!”

It led me to think, possibly a different way to say it…

“It couldn’t be that simple!”

Because I think what Ron is getting at — at least this is what I believe to be true — is that, many times, folks over-complicate things.

In addition, folks often confuse simple and easy: just because something is simple doesn’t mean it is easy.

Conversely, just because something is hard doesn’t mean it is complex. I think sometimes folks run into “hard” things to do, and decide that it has to be complex to justify the degree of “hard.”

Not so…

Keep it simple.

(Now, go look at the date of Ron’s post!)

Agile Won’t Be Killed

13 Replies

UncleBob wrote this good piece on whether Scrum could Kill Agile.

To me, Agile is a mindset, a state of mind, a way to be. It is neither a (set of) coding practice(s), a concrete process, or a management technique.

Agile is not TDD, XP, FDD, Crystal, Scrum, Lean, Kanban, Six Sigma.

Agile is about being responsive to the current and future needs of the business within the current context, so that you can do the very best possible given your team and budget. Read these again:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The “we value the left-hand items over the right-hand items” is precisely loose because it all depends on the context and the business needs. Believe me, we argued mightily over small wording changes in that Snowbird meeting! It’s just that in general, our collective experiences had born out the truths that we were more effective and responsive to delivering valuable software when we emphasized the left-hand items. I was coming from the government background, and I was determined to demand we push for truth and honesty in software. No more stupid 70% done and no working software to show for it!

I submit that the Agile Manifesto tenets are irrefutable ideas and will stand the test of time.

The Non-agile Manifesto

Let’s try a little negative test (if you agree to these, I’ll poke you with a hot stick):

  • We will build software with processes and tools — that way we don’t need to worry about people issues and effective communication.
    • That way we can hire any individual regardless of skill, and forgo all verbal/personal interactions in favor of solely written words. Even better if those written words are automatically transformed into code. Maybe we can get non-coder tools! After all, people are merely fungible assets/resources, and software is factory-work — with processes and tools, and a horde of low-paid serfs, we can crank it out!
  • We would rather spend exorbitant sums of money producing comprehensive documentation than have tangible, working results early on.
    • We start with complete requirements specifications (often 400 pages), that follow our company standard template.
    • Even our Use Cases follow a mandatory 3-level deep path, with proper exception and alternate paths worked out.
    • We link the requirements items into detailed design documents — which include system design diagrams, interface specifications, and detailed object models.
    • If we don’t write it all down now, we’re likely to forget what we wanted. And if we don’t do it to the n-th degree, the developers might screw it up.
    • Writing it all down up front allows us to go on vacation while the process and tools “write” the code from the detailed specs/diagrams. Sweet.
    • In addition, we love to be rewarded by reaching meaningless intermediate deadlines that we place on our 1500-node Gantt chart.
    • When we combine all of the upfront work with a important deadlines, many of the senior managers can get promoted due to their great commitment to generating reams of cool-looking documents. By the time the sh!t hits the fan when folks realize the “ship it” deadline is missed, the senior managers are no longer involved.
    • Besides, if we actually built software instead of writing all sorts of documents thinking about building software, our little ruse would be exposed! (BTW: if the human race had done nothing more than documented the ideas about how best to go about procreating, we wouldn’t be here to waste software budgets. w00t!)
  • We prefer to write a tight Statement of Work & force a strict fixed-price contract rather than actually work towards a common goal with the client.
    • The agreement is based on the 400-page, fully-specified requirements document, and we pad the cost estimate with a 400% profit margin.
    • We then hire dozens of people to argue during the Change Control Review Board monthly meetings about re-writing code to deliver what you wanted versus what you asked for when you thought you knew what you wanted (and wrote it down in that 400-page doc).
    • Contract negotiation pissing matches are such great uses of our collective resources and always result in perfect software! We love our fine print 🙂
    • With a 400% padding, the projects are too big to fail.
    • Once we are in it for 1 or 2 million and 50% done and 2x schedule overrun, who would ever say “No” to a contract extension? Who better to get you to the goal line than the same folks who squandered away your treasure, pissed away the calendar, and delivered no working software yet?
    • We like to appear like we’re just about done… Asymptote? Never heard of one.
  • There’s nothing more appealing than following a 1500-node Gantt chart. To the letter and subletter. Change sucks.
    • Especially a Gantt chart that has been built with tender loving care to include resource allocations, inter-project dependencies, and partial resource allocation assignments for matrix-style organizations.
    • We love hiring a small army to ensure that we drive the entire team to meet every micro-task deadline even when they no longer make any sense.
    • The real fun is collecting the “actuals” data from the developers assigned to each task.
    • And nothing sweeter than seeing 90% of our tasks being started, and 75% of those being 67% completed, and 25% of them being 99% completed — the roll-up summary to management is such a compelling story.
    • Changing such a beautiful plan that took 4 man-years to develop, that incorporates all of the comprehensive non-code documents, and is an appendix in the contract, is no small feat!
    • Better to produce the software according to plan even if nobody wants it that way. That’s our motto, and we’re not going to change!

Waterfall Sucks

Waterfall — as practiced — will die under it’s own weight. Waterfall is a bad idea when applied broadly to all sorts of classes of software projects. Eventually people will wake up and realize that — for many situations — there are better ways to doing software than waterfall. (Waterfall done on one feature at a time is a fine practice 🙂

I remember seeing folks who worked for Big Consulting Firm go into an organization to do all of the Use Cases for 9 months straight. Their documents were then handed off to some other firm to do the analysis and design. And finally, yet another firm would do the implementation based on the sum total of documents. Since the written word left nothing to the imagination, these projects always delivered perfectly. Oh, wait. Standish Group says that really isn’t how things worked out. This might be an okay way to go about hardware or construction projects — since you can be more deterministic up front, and there are more common parameters that are “agreeable” to most folks in terms of real interface documents (like engineering or architectural drawings are pretty specific and not ambiguous). But to anyone that has any experience in software development, waterfall seems ludicrous from Day One! Who would ever think that you could hand off all features as they went through each of the major phases with no loss of understanding? Who would ever think it is good to wait FOREVER to see any tangible results? After all, we’re NOT bending metal or breaking ground. It’s freaking software! Sigh.

Waterfall seemed ludicrous to me my very first time. I was exposed to Mil-STD-2167 while doing DOD contracting in the 80s. I think I followed along like a good little well-behaved junior engineer my first time. Probably even my second. Then my brain kicked in and said — this is stupid for our situation. We’re doing software development for R&D projects, we’re not doing assembly line work for a brick factory. We can’t know everything up front, and it is risky to think you can! So I started to look for better ways, and began to not do wasteful practices, even though they were prescribed. I began to do the right thing for the customer — and they agreed to the <ahem> “waivers.” (I was applying the “Better to beg forgiveness, than ask permission” principle I learned from my good friend and mentor, USMC Colonel Rich “Magic” Dinkel, fighter pilot extraordinaire.)

I sound like I am bashing people that did Waterfall… I don’t want to be that harsh. People did what they thought was best at the time. I think many times we fall into a trap of wishful thinking. And even in the face of overwhelming observations to the contrary, we soldier on in hopes things will work out like we want. (Besides, it’s in the contract!) Rarely is hope ever a good strategy. Maybe never? So folks doing waterfall certainly had good intentions, and it was compartmentalized enough to reward intermediate victories and give an illusion of progress, but there’s no denying it’s just a bad idea.

Agile didn’t kill Waterfall per se. Sure, maybe it helped accelerate the community’s realization that there were better ways to do software than a giant, rigid, 4-stage assembly line.

Waterfall killed waterfall.

Scrum Won’t Kill Agile

I say let the Scrum Fun continue! Make tons of money! Waste as much budget as you can. Brag that you are doing Scrum and have hired 20 CSMs to whip your developers into shape!

The more people and HR departments that think there is some magic bullet, the more companies that might fail and lose business. This makes way for smarter, leaner, more entrepreneurial start-ups to eat their lunch. After all, I would wager that very few small organizations are falling for the Scrum Will Save The Day stupidity that is seemingly gripping some (large?) portion of our community.

Convenient Cover?

Here are a few phrases that come to mind regarding the Scrum dustup, and I’ll add a new one…

  • A friend once quipped that “Off-shoring is just a cheaper way to fail” — implying that if you can’t build software locally, you probably can’t build it 12 time zones away either. But at least the costs are lower.
  • No one was ever fired for hiring IBM
  • We are doing Scrum — all the rage in Management By Magazine circles!

In other words, it is often far easier to go with the flow, follow the herd, live by the plan, and say you did what you were told. It is much harder to buck the system and call out the ineffective and wasteful activities, and continuously try to improve. It’s hard to buck inertia!

Conclusion

Nothing will ever kill agile.

Bold, I know. However, I view it like the USA’s founding principles — immutable laws of freedom. Agile is about freedom to do the right thing.

How can you ever deny the correct way to do software is to do what’s best for the business?

How can you deny the Agile Manifesto tenets?!

Successful software will continue to be developed in an agile manner, regardless of the terms that might become popularized.

Response to “Three Things I Don’t Like in Agile Community”

3 Replies

Andy wrote some interesting observations in his “Three Things…” post:

1. Dogmatism
Agile is about adaptive, creative approach to complex work yet amazingly average agilists are the most dogmatic people I know.

Part of dogmatism is also treating agile […] as the all-encompassing solution to problems not only in software development, not only in IT, but everywhere. [This] is a far cry from healthy pragmatism that I think is at the core of all good management.

I see this is a common thread among those who have issues with Agile. Naturally, if someone is presenting a methodology at a conference, I can see where it might sound dogmatic. However, if an Agile Consultant is engaged with a team and preaches “Do it My Way or Else” in spite of vehement team opposition, well, that strikes me as non-agile.

For me, agile has always been more about the proper state of mind than dogma. We need to prefer to do those things that are best for the business/customer goals over doing things that are not as helpful at getting the project closer to “done.” Sure, there are practices associated with agile methods, but simply doing those practices don’t make someone agile per se.

No, what makes someone agile is a combination of what they are doing, how they are doing it, and all within the cultural and business context in which things are being done.

For example, you just can’t walk into an elderly long-term care facility and do yoga like you would with 20-30 year-olds. (Well, you could, but that would be stupid.) Similarly, you can’t simply ram your favorite XP tools and practices and Magic Scrumbans into a steeped-in-old-ways, very stodgy organization full of legacy software written in a 30 year-old, no-longer-supported language. Well, you could, but that would be stupid.

So, Andy, if you spot one of us “Agilistas” spouting off a dogma, smack us upside the head and say “Work with me, son!”

2. Sectarianism

Kanban, Scrum, XP – everyone follows their own method, and basically says others are useless or at least not as good. […] Again, this is in the face of core principles of agile.

Hmmmm. The only good method I ever practiced was the one I was doing at the time it was working right. While I can understand someone who is training in a strict methodology being sectarian, that is not the same as consulting. I attempt to be a generalizing specialist (as Scott Ambler likes to refer to it…) and use a blend of tools, practices, modalities, and therapies.

Andy, if you find yourself being preached to by a consultant (not a trainer) that is one-dimensional, take it for what it is worth. A single, focused, dimension — nothing more.

3. Domination by consultants Most if not all agilists that write, teach and coach do only this, and have not run a software project (or a business) hands on for quite a while.

Well, the lack of real-world experience should be obvious by perusing their background. While trainers can be good at getting across certain practices and methodologies, and while coaching dozens of teams provides valuable exposure, it does not substitute for actual production experience. I learned a great deal traipsing around dozens of companies to help train and consult to kick-start projects — lots of cross-pollination potential as well! Similarly, consultants with great experience at building real world systems and helping teams do that, may not be the best down-and-dirty, nitty-gritty trainer for a given technique.

It’s a trade-off. First off, don’t confuse training on a skill, with consulting to help achieve a business goal. I think you have to understand what the purpose of the consulting engagement is, and who was brought in for that task. If you just want to learn the mechanics and lingo of Scrum, it takes only two days — it’s that simple. But tell any Project Manager with real world software project experience, and they’ll tell you that you don’t know much after just a few days of training.

So, if you ran into an agilista trainer that has not been on a real world project to deliver production code in a long while — or ever, then you should not expect that sort of knowledge. It doesn’t mean they cannot provide you with valuable training.

However, I will also say that not much is new under the sun in software development in the past 30 years. I mean, seriously. The same core issues exist in trying to roll out a piece of software to production as did 30 years ago. Admittedly, I don’t recall having quite as much fun as I do now with delivering production code with Ruby, Rails, Cucumber, RSpec, github, Mongo, gems… The ecosystem makes it so much easier to “do the right thing” with BDD/TDD for example.

Andy, I can appreciate your observations about the “Agile Community” — like so many others I have read on the web. To that end, I suppose we need to re-double our efforts at re-stating that Agile is a State of Mind, not a set of dogmatic practices.

And, in the end, Andy, caveat emptor. The Agile mantra should be one of empowerment and individual freedom to please the customer in the best way possible. You are ultimately responsible for doing the right thing. Agile ideas, processes, tools, trainers and consultants are just that — and nothing more. We are not the answer, we just try to help. In the end, the team is the answer.

Certification is a Good Thing

6 Replies

I read with pleasure “The Value of Certification” from Pawel Brodzinski, that emanated from a discussion about evaluating employees.

Pawel points out some obvious pros to certification, and one big con:

  • It’s objective measurement
  • It’s butt-simple (Pawel didn’t actually say this, that’s, ummm, me talkin’)
  • It’s, and I quote, “pretty much useless”

Then it dawned on me. College degrees are certificates, as are high school diplomas. So are participation trophies for the poor schlubs who didn’t win anything at tweeny league and are (defenselessly) surrounded by adults who mistakenly (IMHO) think such a trophy is meaningful to the kids (kind of like dogfood made to appeal to the purchaser). But that’s a digression…

In our software world, it is the Scrum Certification that bears the brunt of criticism — even though Pawel does not mention this particular style of paper valor. For those who pass an exam after two-days of grueling lectures, practical hands-on training (a.k.a., apprenticing) at the feet of master craftsmen, and in-depth co-op work experience at multiple cutting-edge development shops doing different projects… Oh, wait, that’s not quite fair as that really isn’t what’s going down in just two days. Crap. Scratch that tact.

Anyway, let’s just say many folks seem to be intent on hiring other folks based on Scrum certification (caveat emptor: I do not have said certification, so I am not speaking from direct experience — I’m too cheap to pay for it). I base this on my extensive analysis of randomingly seeing two hiring ads for Scrum Masters that were virtually identical in content — and buffoonery, I might add. For me, it was a big, bad smell for the organization. But, in large bureaucratic organizations (government or MyLargeCo), abdicating responsibility is honed to a fine art. Ergo, the HR departments did what they think was valid trawling for Scrumsters by evidently plagiarizing some sort of HR-i-pedia definition of the perfect Scrumster parameters. Good luck with that. These actions are a boon to your not-as-lazy-or-naive competition (oh, unless you are the Government, which has no competition, only an ever increasing appetite — I’ll not digress here, either).

So, maybe the Scrum Certificate is a bit like a Participation Trophy.

Yea, you were there. You participated. You didn’t actually compete/win or do anything meaningful in the real world to earn it, but there you have it. You should feel better about it. And it does mean that you at least did something (unlike me). Go forth and procreate little Scrumlins. (BTW: I’ve got nothing against Scrum, I think it is a great and simple approach to PM! It’s just hard to pass up the opportunity to poke fun at our own agile software world and make up little monikers as I go.)

So I can look at “certification” in at least two ways:

  1. Basing hiring or performance appraisal on a CSM certificate is pretty awesome for the individual on the receiving end. I bet they didn’t have to go into debt to get one (compared to a college degree)! (Although all of me wants to be judged on my real merits, not on some piece of paper — alas the chicken and the egg comes to mind for newbies.)
  2. If companies find a valuable correlation between a certificate (CSM or otherwise) and knowledge work, I would be surprised. In my experience, the last thing that I would qualify as a trait of software projects, is that they are “cookie-cutter” — that is, where one-size anything fits all (be it ideal Scrum process, database, language, etc.). However, sans external stupidity (like a bailout), companies will “learn” how to treat any software certificate — much as they have with college diplomas and belly buttons (i.e., everyone has one). The market will sort things out, eventually — in that I have faith.

So there you have it. Pawel says “Certification is Pretty Much Useless” — and I disagree. That very aspect of certification will serve a purpose to differentiate those that place undue trust in the paper from those that stick to good hiring practices and good employee relations. I predict the latter prevail.

ps: Pawel, I agree with you in spirit.

Consultant’s Rules?

Leave a reply

Wow, it was a shock to read Gerald Weinberg’s “A Code of Work Rules for Consultants” blog.

While reading the lead-in to his list, I kept finding myself saying “really?” and “ugh!” I enjoy being blissfully ignorant and sheltered, I guess. Here is Gerry’s list:

  1. I will not work for an organization whose goals are not consonant with my beliefs.
  2. I will not work on projects whose goals I do not understand, or cannot agree with.
  3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.
  4. I will not work under measurement schemes that pit one person’s performance against another’s. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.
  5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.
  6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.
  7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

It’s almost a shame that Gerry had to post this list — in that it reflects a state of affairs that he and others have observed (I trust). I naively assume everyone innately follows Gerry’s rules — as I think I have done my entire 35 years of working (including starting out having a paper route in middle school and washing dishes at 15).

Knowing better, however, that your picture of reality is just that, I always advise that folks (employees and consultants, alike) need to be financially sound/independent. If you live paycheck-to-paycheck, it is harder to buck the system than if you have a 6-month or greater cushion of savings.

TIP: Just start out with small goals, putting savings aside until you have one month of living expenses. Before you know it, you will have two months, six months, a year or more! It is truly liberating to have that cushion! Naturally, incur as little debt as possible so you are not haunted by that “anchor.”

So, to Gerry’s initial list, I humbly suggest he add the following:

“8. Be financially sound so that you can stay true to your principles and not be chained to a paycheck.”

Be an Agile Survey Monkey

1 Reply

There’s seemingly quite a bit of a dust-up over assorted agile surveys:

  • Scott Ambler’s 2010 Scrum Certification Survey.
  • VersionOne’s “State of Agile” survey.

I did Scott’s simple survey last week. I did the VersionOne not-so-simple survey the other day.

After someone dissed Scott’s efforts and praised the VersionOne effort, I replied:

I could poke serious holes in the “State of Agile” survey. I mentioned a flaw or two back to VersionOne (i.e., I replied to the email with the link).

But I won’t. It isn’t worth my time.

Surveys are extremely hard to design. I submit that the VersionOne survey has a flawed model of development projects underlying the questions—not that it stopped me from supplying answers. And when you toss it out to self-selection, it gets even weirder to draw major conclusions. And to get subjective info on being more productive with agile, etc., is anything but accurate.

If people make decisions based solely on someone’s survey (or certification or education), it’s a free country.

Good luck with that.

I would never be so foolish.

Why Coding is Not Like Woodworking

Leave a reply

In addition to my opinion that coding excellence is more akin to personal discipline, a la yoga, I think that software has an intrinsic escape hatch/built-in flaw (so to speak).

The feedback loop on software is often simply whether the client was happy with the feature. (Or the boss being happy with the work effort.)

Now, if the developer gets positive feedback even though they might not have coded it as good as an expert, what would drive them to think they need to do better that that? I submit: only an internal drive to push yourself, to stretch your mind, to see if there are alternative ways to do things more effectively. And that is not the norm in most professions, and quite probably not the norm in the software profession.

Most folks are satisfied at doing a “good job” as defined by their “clients.” And why shouldn’t they be?

Were our profession more like woodworking or even music, I think we would have an easier time spotting the difference between a mediocre woodworker, a competent woodworker, and a master craftsman woodworker. In woodworking or music, lousy technique is very evident — even to the lay person. From poor design aesthetic, to poor construction technique, to bad finishing.

So, we continue to struggle to show the downstream impact of today’s decisions. How can we improve this?

Why Coding is Like Yoga

Leave a reply

This has been nagging me for a while… like it is an answer, maybe. I’m curious what you might think.

I have sort of determined that writing code is more like yoga, rock climbing, or mountain climbing. It is mostly personal and all about self discipline. Extrinsic motivation has some measure of effectiveness, but I submit that it is largely intrinsic motivation that makes any of us do what we do.

In yoga, it is all personal. I do “battle” only with myself. If I don’t get as much into or out of a pose, i cheat only my own body. So this is like when I am doing relatively isolated coding work on a project. However, when my body or skills are required to be part of a team, now the cheating of my own self can impact others.

For example, when I am working on bits that touch others’ work (common in coding), it is more like alpineering/mountain/rock/ice climbing. The actions of the other guy(s) on my rope will impact me to a great degree (and vice versa). Fortunately I can work with my close buddy and ensure proper protection and that we are making smart decisions. You see, in mountaineering — like in coding — you constantly need to be evaluating risk, as changes occur every step of the way (literally).

Another parallel to alpineering: My roped team might be fine and dandy and making good progress towards our goal. But believe me, we care a lot about other teams on the same route (for some routes are more crowded than others). Someone else’s carelessness can wipe us right off the mountain. So we are motivated to ensure that other people are safe, or that we are not exposing ourselves to their foolishness. (Ever get “bitten” by someone else’s rotten code?)

In each example, what I do regarding achieving the goal very much depends solely on my commitment to do the right thing. It depends a lot on discipline (hard to always do BDD and not just sling code). It depends a lot on being in good shape and having mental toughness (constantly learning new things surrounding coding). It depends a lot on being able to at once see the big picture (why am I writing this), but also be able to dive deep into the details (down-n-dirty coding).

So, try as we might, there is no way to get around the fact that coding is a individual team sport. Another analogy that might help cement this idea of mine:  coding might be closer to gymnastics “team” competition (with individual performances counting a great deal towards the team’s success) than, say, football (of both kinds).

Get your practice on!

Motivational Posters

1 Reply

The sight of motivational posters and laminated “corporate” values posters plastered around the conference room always raises my antennae.

It is frequently a portent of an organization full of well-meaning folks mistaking activity for progress.

Maybe that is why i like de-motivational posters so much 😐