Posts Tagged: agile


8
Sep 10

Agile Intifada

This blog post was inspired by a link my friend sent me titled “Agile Ruined My Life” as well as a conversation with my friends/co-workers and just wanting to clear up a few things about my previous “Agile Dilemma” post.

Some of this is taken verbatim from an email exchange between myself and a few friends I greatly respect.

I agree/like agile in theory and practice. I agree and like TDD in theory and practice. Anything that makes it mainstream can be scathed and unfairly criticized. So now that I have this out of the way, and I will clarify it later, the rest of the post won’t be so nice for some. (WARNING: It will sound a bit harsh to some ears, with the hope of being constructive.) With that I wish that if nothing else, the few that read this blog post will reflect upon it and critique constructively.

I wrote the Agile Dilemma post mostly while I was letting off steam about computer science itself becoming extinct in lieu of a bunch of bullshit consultants pushing agile and TDD 90% of the time without teaching people how to actually design and write good software. I think lots of failures in our industry are due to the fact that most folks don’t know shit about programming and computer science, they just know a language or few and eventually learn how to express some intention utilizing these languages. That’s like comparing a native speaker or someone who’s learned and practiced the art of a foreign language for years, with someone who’s learned how to ask for directions after listening to RosettaStone audios. From a business perspective most pointy-haired bosses don’t give a shit. It works and the business development teams can do their “magic”, but from a perspective of a computer scientist (the real software developer) it stinks. It smell of amateur manure (no matter how many tests your write to prove that the action button works).

Now, there are those that go even as far as saying that non-TDD written code is “stone age” or that programmers not practicing agile, TDD, pair-programming and all the other process bullshit are not “good” programmers or shouldn’t be programming. Well, then shut down your linux/unix operating systems, stop using emacs or most other editors, as a matter of fact, stop using 90% of the stuff that you’re currently using, because most of it was written by these “stone age” programmers who didn’t give a fuck about formalities of agile or TDD, but created masterpieces because they were smart, motivated, and knew how to program with common sense.

Before I get into detail, I’d love for people to stop petitioning for turning opinions formed by so called “experts”, into commandments. Just because Martin Fowler, Robert Martin, or name your own Agile Mythology Deity say it is so, doesn’t mean much more than anyone else in the field with experience. They are human just like me and you and form their own opinions just like me and you. The only thing they are better than the average at, is marketing. Yes, they are sales folks with large investments in agile, TDD, etc… in their consulting business, so I don’t think I go overboard by saying that they are a bit biased. Spreading FUD brings them more business. As one of the above links pointed out, Peter Norvig, Linus Torvalds, and hundreds of other brilliant programmers (far more brilliant individually than Fowler and Martin combined), have been programming successfully for decades not using any formal methodologies and techniques and not following TDD and have succeeded beyond their wildest dreams. I’ll take one Norvig over 50 Fowlers any day.

Writing tests is not innovative, it’s been around for decades. It was just never formalized. Yes, there weren’t as many tests written or sometimes none, programmers actually got to decide whether a test was needed or not. Programmers are sometimes overly optimistic, so yes, mistakes were made, code had bugs, stuff was rewritten. Decades later, TDD and Agile at hand, mistakes are made, code still has bugs, stuff still gets rewritten. Now put that on your t-shirt along with your favorite TDD blurb.

So I had an interview about two years ago, where I was asked two questions that after reading this post, folks should immediately take off their interview questionnaire if they ever want to hire someone good. The first question, wasn’t as bad, but it wanted me to recite some design patterns. I’m all too well familiar with those, probably more than I want to as this point, but familiarity with patterns doesn’t in any way exclude anyone from the “good” programmer group. The second question was the worst, they wanted to know how many lines of test code I write per week. I had to pause and then ask them to ask again, as I was puzzled. WTF does that mean? I don’t know how many lines of non-test code I write per week, you want me to count/average the amount of tests I write? I mean, I see if the question was if I practice TDD, but lines of fucking test code? Either way, just to clarify that I’m not bitter and that’s why I’m mentioning this, the interview went very well, we just couldn’t come to terms on salary.

Agile is also not innovative. I’d like to think of agile as an abstract set of empirical ideas (patterns), with implementations left to the people/companies. Lately though, because there is really not much more one can write about the few agile principles, most literature about agile is about concrete agile practices through author’s experiences. These are all great reads only if people would read and take them for what they are “experiences”. We should learn from experiences, not try to recreate them. Agile approach is common sense that has been practiced for decades in different circles. Iterations are common sense, they were practiced for as long as programming existed, tests are also common sense, actually most of agile is just good common sense approaches to building products. Formalizing it actually helped quite a bit, as the industry was able to reason about it and transfer the empirical knowledge to others with less experience. But then, as with anything mainstream, the bureaucrats took over, and it’s IMO been down the hill ever since. Actually, some recent attempts at quantifying agile’s success have failed to show it to be any better (within a margin of error) than any other process or no process at all. That’s not to say that it’s not successful, it’s been very successful for many, including me and the companies I worked with. The failures that folks are seeing are due to many reasons, but partly because in most companies agile is practiced as a bureaucratic rule of thumb, without any common sense. Folks are forced to write comprehensive test suites. The “comprehensive” is something inferred and quantified by quality control tools, that apply bullshit heuristics. But managers love it, it gives them numbers and pie charts. So programmers (even the ones that love programming as more than just a day job), do what ever it takes to keep the job, they write comprehensive tests and bullshit software. At the end of the day, who gives a crap if your algorithm is exponential complexity and mine is logarithmic, the tests pass and the sales can go on. But what about folks that actually love what they do (computer science)?

So let’s get back to basics. Learn computer science, algorithms, data structures, language theory and practice. You’re never done learning. Go out and create your own masterpieces. Don’t let the agile Deities full you into thinking that your software isn’t worthy if you didn’t pass a TDD heuristic or if you don’t hold daily standup meetings. No one knows you and your team better than you. DO WHAT MAKES SENSE FOR YOU AND YOUR TEAM!

DISCLAIMER: No agile enthusiasts were harmed in this experiment, including myself.


2
Apr 10

Agile dilemma

The time has come to truly retire the word agile. I like the word. I love the idea of agility. But I’m starting to dislike how it’s starting to constrain software development and how it’s endlessly used in software literature these days for the lack of anything else to talk about I guess.

What was supposed to be as phrased in the agile manifesto:

Individuals and interactions over processes and tools

has become infested with these non-developer type parasites who at any sign of anything having a chance of making mainstream, inject their bureaucratic venom into it forcing a self preservation act by most smart developers. That act is to run for the hills.

So what happens next? Well, its a never ending lifecycle. Agile will reincarnate as something very similar to where its origins once lie, but in smaller development circles, until it’s crippled again. This cycle will repeat indefinitely. This cycle is not only apparent in software development lifecycle methodologies, but also in programming languages, frameworks, etc…

Software development is as much art as it is science and engineering. I think when some hear engineering, they think bridge engineering or what today has almost become a ubiquitous term for anyone doing anything. In engineering a bridge, one can reproduce rather predictable set of results. In developing software, one can’t. Engineering is as American Engineers’ Council for Professional Development put it: The creative application of scientific principles to design… Creative is the keyword here. Not constrained by process the kills creativity. We as professionals should be able to discerns these things and stop applying absolutes to the creative process. Just because we have successfully applied processes in the manufacturing discipline, doesn’t mean that same processes or processes at all, can be applied to software engineering. Sorry folks, no software factories for you.

Useful precise estimation is a delusion, and the sooner we realize it, the faster we can get back to developing quality software. Process is disadvantageous. All designed to give the businesses a warm fuzzy feeling of certainty around something that’s not certain. So why are there some that can give good estimates? There are only two reasons. One is that they are lucky. No really, they are lucky at predicting the unpredictable. This happens, trust me. Just ask someone who has a financial advisor and trusts them to set up their financial investment portfolio. Do you trust your financial advisor? If you do, please read Fooled by Randomness and The Black Swan. Also, there is actually one other reason for good estimation. Sorry developers for exposing this to your managers. This reason is overestimation. Yes, you heard it right. You overestimate, then you finish your task early, but instead of looking good by marking it as done early, which will in turn screw up estimation reports at the end of the sprint by showing that you chronically overestimate, you choose not to and though find something else to do to kill time or start on another task in case that one turns out to be underestimated. At the end of the project, you have accumulated so much time, that your friends have to ignore you on facebook and un-follow you on twitter.

One might say it doesn’t matter, as long as the overall estimates are close. Well, whatever makes you sleep better at night. Just know, software estimation is not science, it’s gambling.

Ah, one other thing, mostly related to XP. My favorite topic, Pair Programming. Sorry folks, this one’s not really for me. There are many issues with it. First, it’s disruptive in the way I think and to my personal creative process (I’m sure it’s not just me either). When I think, I don’t want anyone interrupting my train of thought just because they have an idea. Great, but if your idea doesn’t pan out, my idea just got lost in the shuffle, thanks for the context switch partner. In any other field that requires critical thinking, people work alone a lot (maybe not all the time). Just ask all the researchers. They come up with their best ideas/research and when ready, share those with colleagues or other researchers. They don’t gather up in a room and participate in committee based research. That would never work. One might say it’s because they are egotists. That might be true, but that’s not necessarily a bad quality being that it drives them to outperform someone else. At the end of the day, most innovations come from these weird acting egotists.

In pair programming, we have to be on the same schedule. When my brain doesn’t click, I like to go for a walk or pace around the room to get me into the creative process again. A lot of my ideas come not when I’m sitting at the desk writing code. Now, do I have to coordinate that schedule with my pairing partner? Should we hold hands and skip together? What about if I want to use the bathroom or grab a cup of tea? Should I be conscious as to ensure our bathroom/tea schedules are in synch? Are you kidding me? What is this, grade school all over again or a software factory (laughably some actually like that term).

Well here it goes. I’m a software artist/developer. I write code because I love to, not only because someone’s paying me big bucks to do it. I get aroused by solution revelations and enjoy compliments when I solve hard problems before others, or that others couldn’t, or in a more elegant/concise way than others. Software development is a creative process. It brings with it the ability to create a masterpiece. It’s also a process that requires critical thinking, reflection, and most of all “quite”. Private offices are great, but sometimes not realistic depending on the company’s financial situation. The office doesn’t have to be private, as long as what ever your arrangement is, it’s quite enough and not distracting for you to do your work without having to context switch every 10 minutes to hear some rant going on around you and/or answer questions. There are time for questions, but not when you’re in the zone.

I’d like to see Michelangelo or da Vinci create masterpieces under the constraints of a process. Better yet, I’d love to see those two pair paint.

We all don’t think or work the same. We’re humans. The key to good software is to hire great smart developers that can hold their own. Keep the teams small. The rest will be worked out as a team not as a process. It’s about common sense and good people, not processes.