Take close note:
unequivocally successful development project.
An “unequivocally successful development project” is on time, on budget, fulfills all goals and meets the usage predictions defined before. That’s rare.
It is very well known that most software misses that mark. I’d also argue that many projects of other kinds miss that mark, unless they are repetitions of previously done work. Large buildings regularly overshoot their budget by magnitudes. New train tracks often fail in spectacular ways. Next to my home is one of the largest train station in Europe (used to be the biggest) that was never used for long distance trains, as another hub was preferred. Newly started companies go bankrupt by the dozens daily. Plane engines explode in mid-flight (luckily to no harm, very often).
My best project ever, far under budget, a huge component-based system quickly built and certified was a failure, as it couldn’t be launched for legal reasons that would have blown the budget. It was also a huge success from the technical standpoint.
If 19% of all projects are “unequivocally successful”, that’s great.
I do specialized consulting, so I only build parts of systems. Most of the time, I don’t even see the end-product as part of the team. Or, most of the time, I see the project on the edge of failure. I do, almost by definition, never work on an “unequivocally successful” project. And that’s not something you need to feel bad about and you shouldn’t think people doing this work are less good.
Out of curiosity, what kind of consulting do you do?
“Everything where data flows”. Databases and distributed systems, often Elasticsearch, CouchDB and several queuing mechanisms. I often come in as a firefighter, sadly, as most people don’t set out to build a distributed system :). Or, in less stressful environments, it’s just old, has problems and they need someone to point them the way.
Sounds interesting! I’m starting my own consulting practice right now (scaling Heroku-hosted Rails apps) and I’d love to chat and share experiences. If you also think it’s a good idea, please shoot me an email to the address from my profile (I cannot find yours email anywhere).
I’m not really interested in the “Let’s pile on about Agile” critique…let’s look at this from a different angle.
What is it to be on a successful project, exactly?
From a purely technical perspective, it’s having elegance of the code and (more importantly) flawless/bugfree coverage of the use cases. It’s having clever ideas implemented well, and knowing when you can get by with a nonclever idea. This is why, for example, I’ve got a handful of little support libraries out there for things like vector and graphics math: they’re small polished tools that are well-designed and well-tested.
In open-source, you can kinda look at the number of users of your package and numbers of contributors as whether or not it is successful. You might even look at number of forks. :)
In industry, you look at how it moved the company’s bottom line. You look at who gets promotions or recognition, and who gets bonuses.
The problem is, I think, that none of those is a metric without problems.
Any number of purely technical successes are transient: no matter how well made, they will become inferior to later innovation. I believe that this applies not only to the shiny treadmill of webtech, but to things like gcc falling to clang and C++ to more modern languages. Additionally, only somebody of decent technical skill can recognize a technical success–the author may not even recognize it!
Open-source has a problem of visibility: lots of people dogpile onto whatever is popular without thought for its merits (cough Angular cough). Furthermore, the projects which collects the most participation are the ones that are buggy pieces of shit…code that just works is just quietly included and unacknowledged, usually. Finally, the community has a selection bias for folks that shamelessly promote their own work and that care to play people politics (systemd, pulseaudio, Angular again, Rust).
In industry, the number of companies that are setup to track these performance metrics is not great. First, it’s rare that a genuinely new piece of software is being written–more likely, an incremental improvement is being made to an existing codebase. Thus, contributors are seen as doing maintenance and not creation, and may not be rewarded at all above their base salary (this was one reason I left my last job…the startup had nontrivial technical debt, and with my own BEAR HANDS I’d build the first version of half of the system and refined later versions; because mine was not the name on the first commit, the CEO insisted that only the CTO had written anything worth recognizing). Secondly, there is not really a culture of recognition in any meaningful sense: we don’t get commission, we don’t get rewarded, and usually we don’t get time off after a feature is delivered. Working in industry seems to be basically a never-ending occupation of a desolate and hostile warzone^Wsoftware project.
True, and underreported. A large number of software engineers seem to leave (one way or another) after 10 years without a genuine success to speak of. Even though they weren’t making the decisions, the stink of failure is hard to wash away. Founders get their investors to vouch for them that they worked hard and failed in good faith, in exchange for not exposing the investors' business practices. Programmers, on the other hand, get washed out of the industry if they haven’t been on at least one successful project– and I’d guess that 90 percent fail. Not all of those failures are complete failures that didn’t add any business value, but I’d guess that 90% of software efforts perform poorly enough that non-managerial people don’t gain any credibility from having worked on them.
I don’t necessarily agree that “methodologies” can help. To start, software is hard. We’re trying to solve problems that haven’t been solved before, and a 30 to 50 percent success rate would be quite good in any case. Add in business-driven engineering, whether it’s Waterfall or Agile (same shit, different stink), and all the other startup-land horse-shit (no senior hires, open-plan offices meaning code never gets read because that’s just not possible in an open-plan environment) you’re probably down to 5-10 percent.
If the success rate’s 10 percent and you get one project every 18 months, then 48% of engineers are going to go a full decade without seeing a successful project, at which point they either need to start thinking about climbing corporate ladders, going independent, or doing something else, because the all of the traditional doors worth opening (e.g. the AI groups at Google and Facebook, the few startups actually worth working at) have closed to them.
I know your views on agile and I don’t expect to change your mind, but for the record my experience has been that methodology makes a huge difference and agility directly correlates with effectiveness.
I don’t think any of the projects I’ve worked on have even been visible outside of that particular company. So I can’t see it affecting hiring. Maybe that’s my particular background though.
I find myself nodding in agreement with @michaelochurch a lot about Agile because I’m currently in my fourth instance of an Agile team and each time it’s meant something very different. In fact, those running the show have just taken what they wanted to do and labelled it as “Agile”. It’s ranged from Scrum, to “do what you want”, to clearly a waterfall approach with a trendy name. To me, it’s a meaningless term, but it’s always touted as a “winning methodology”.
I don’t have anything against the idea of methodology, but I do have an intense skepticism of them.
those running the show have just taken what they wanted to do and labelled it as “Agile”. It’s ranged from Scrum, to “do what you want”, to clearly a waterfall approach with a trendy name. To me, it’s a meaningless term, but it’s always touted as a “winning methodology”.
But Agile does have a very clear meaning: the manifesto. Even if the company’s just calling itself agile to start with, the manifesto gives you a weapon to advocate better practices with.
Even if the company’s just calling itself agile to start with, the manifesto gives you a weapon to advocate better practices with.
However, by corporate charter, the boss has a much bigger dic^H^H^H weapon, which is the ability to fire you. So it isn’t clear to me that the Manifesto helps. (This problem is beyond the reach of methodologies. We’d need to unionize to make in-roads, and that’s not popular in developer circles.)
Perhaps that is my issue with “Agile”. There’s a lot of dog-whistling going on with it. It’s sold to management as a mechanism for control and as a first step toward a style of aggressive (and often counter-productive) performance management that’s in vogue these days (because people overvalue “making hard choices” and assume that if something’s mean-spirited, it probably gets more work out of people). It’s sold to programmers as a substitute for getting our shit together and actually organizing or professionalizing. It doesn’t get either side what they really want, but we get an even shorter end of the stick.
I wonder how much of what you’re ascribing to “Agile” is really just “startup culture” in general? Working at a stable software company outside of startupistan that uses Agile methodologies, I don’t really recognize much of the description.
Your boss can of course overrule you. That’s part of their job, and occasionally necessary. But by declaring themselves “agile” your boss has agreed that they understand or at least accept a particular definition of good engineering practice. When a disagreement is just a matter of opinion the boss' opinion wins every time. When it’s about your boss asking you to do something contrary to agreed policy that’s a very different conversation. Most bosses like to think of themselves as reasonable people; when a boss makes a poor technical decision it’s rarely (IME) due to a deliberate desire to sabotage a project, or even a decision that will benefit them at the expense of engineering; rather they’re trying to make the best decision they can, but not conscious of the value of direct technical experience or the rate of change in the industry that can invalidate even quite recent knowledge, and fall back on hierarchy. That’s the sort of thing a methodology can give a lot of help with.
(Of course some bosses are simply outright unreasonable, or deny having agreed anything, or attempt to get you fired for trying to reason with them, and your only real recourse when faced with such a boss is to quit. That’s a real problem that agile does nothing to solve. But I think that’s a problem in any industry, and while I support unionization I don’t think a union could fully solve it (a union could probably prevent an unreasonable manager from getting you fired on a whim, but not from sabotaging your promotion chances, except by going to pure seniority-based promotion/pay, which probably creates more problems than it solves))
 Both things that are very different in today’s workplace from what they were the ancestral environment, so it’s unsurprising that human reasoning would be poorly adapted to dealing with them.
Your boss can of course overrule you.
So why pretend differently? Why have a process at all, if it provides no protection? See, this Agile stuff is sold as offering benefits to both sides: developers get protected from capricious management, and managers get visibility into how the work is done and when. If developers aren’t getting real protection, then why do they have to pay into the system that seems to legitimize micromanagement?
What’s disgusting about contemporary startup culture is that it expects people to work like alphas, while being treated and compensated like betas. Anyone mature says: pick one or the other. I’ll work my ass off and call shots, or I’ll be a disengaged order-follower and do the minimum. Unfortunately, there are just enough naifs that the startup ruse works– on people too inexperienced to know that they’re actually betas who will never advance.
My experience isn’t that it legitimizes micromanagement, but just the opposite: under agile management is circumscribed, all the manager is supposed to do is set priorities once every two weeks (and I guess if something’s raised in standup as not on track - but that’s more at development’s instigation).
What’s with all the emotional language and kooky terminology? You’re not like this on other topics.
kooky terminology aside, my experience has also sadly been that “agile” is indeed used as an excuse to legitimise micromanagement (tons of unnecessary meetings, developers being pressured for timelines and estimates before they’ve had time to spec out the problem fully, and constant work interruptions to have status update talks)
By kooky terminology, do you mean “alpha” and “beta”? I thought that those terms were pretty mainstream.
Process doesn’t provide perfect protection, but it certainly is better than nothing. You can quibble with the methodology, or the implementation, but saying that anything less than ideal is pointless just seems really self-limiting.
I’m currently in my fourth instance of an Agile team and each time it’s meant something very different. In fact, those running the show have just taken what they wanted to do and labelled it as “Agile”.
I found this aspect of your post confusing. Those two sentences seem contradictory. Were you on four Agile teams? Or were you on four non-Agile teams where your boss was implicitly requiring everyone to lie about it’s non-Agile nature?
Four different teams, four different companies, none concurrently, each outwardly projecting the notion is was/is Agile. Internally, each was run in a way that was radically different than the others.
Methodology does make a huge difference. The problem is that it’s mostly a negative one.
I’m a fan of the “hire smart people and trust them” methodology. That’s where I stand.
There’s some good in the Agile Manifesto, and iterative development is, on the whole, a good thing. I just don’t like Scrum or what “Agile” becomes in the hands of those who are already inclined to micromanagement.
I don’t think any of the projects I’ve worked on have even been visible outside of that particular company.
Fair enough, but I feel like a good interviewer can get a sense of whether the projects you worked on were valued by the business.
MBA Culture types are all about “teamwork” (don’t get me fucking started; it’s not even 7:00 yet and mornings are supposed to be peaceful) and there are a lot of programmers who get to age 30-40+ and can’t honestly say that they’ve ever landed on a winning team.
What’s a winning team? I’ve worked on harmonious and high-functioning teams that got shut down because of problems upstream, and I’ve worked in hellish, dysfunctional donkey circuses that dominated their industries. Neither can really be called winning, but there was a lot to like in both situations.
What’s a winning team?
That is an excellent question. It seems to be depend on whom you’re trying to impress. Contemporary MBA culture is averse to individual excellence; they want to hear about times when you succeeded as part of a team, which of course requires being on the right team.
Some people are impressed by what the team did, others by the talent level on it, and others by whether you had a leadership role over a large number of people. There’s no consistency to it. Hey, I don’t make the rules.
It’s all contextual, right? What your great-grandboss thinks of as winning may be very different from what you do. I mean, it’s hard to get excited about the Kessel when you froze to death in Stalingrad proper, but the Russians definitely “won” there.
Maybe my choice of analogy betrays some of my thinking vis a vis software development. I think I need more coffee. Possibly a different career.
I found a version of this talk that has partial citations in the first two minutes. I’m ~20m into the talk and have not yet heard the tantilizing claim from the headline; perhaps it was added in a revision of this talk or invented by the article author.
I once met a contractor who told me in private that our project was doomed to fail because no one involved had ever shipped a project before. In some sense, many people can go their whole career without having built something in use and in the field.
And when you get on a successful one, you often wonder how it could possibly be asserted as such.
There are quite a few widely used projects on Github, Rails comes to mind. I can believe that few people who write ruby have participated in rails development, or another major gem, but not seen a successful project?
The vast majority of programmers never contribute to an open-source project, or even program at all outside their jobs.
Maybe I’m unusual, but I run into bugs… if I use rails, I end up looking at pages like https://github.com/turbolinks/turbolinks-classic/issues/665 even if I have no intention of ever contributing to that project, so I certainly see how a successful project handles issues.