Where did all the developers go?
agilewarrior.wordpress.com
agilewarrior.wordpress.com
True Agile:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Getting shit done over attending meetings and conferences90% of what is sold to me as "Agile" is not at all agile. It is unproductive snake-oil sold by people that benefit by playing with numbers, taking credit and acting as whip.
Nowadays the existence of the word in job descriptions is actually a filter for poorly-run companies. Either they unconsciously swallowed the Kool-Aid or there is a lack of managerial trust in the builders and they have chosen to sacrifice work output for an emotionally comforting feeling of control.
The insinuation from many companies that anybody would want Agile processes to work efficiently is ridiculous. Those that work well are agile because they intuitively or consciously follow the original principles and are part of a cohesive team that doesn't do unnecessary work.
I've noticed this, as well. In those friendly little emails LinkedIn keeps sending me, the companies who claim to be big-A Agile are the ones that seem like the least enjoyable to work for. The ones that actually are agile and would be fun to work for find other ways to signal that fact - mostly by using descriptions that show them to be developer-centric and focussed on software.
A friend of mine recently asked me to give a short presentation to a few developers working at his small software company. He suggested that Agile may be a good subject and we spent an hour discussing how his developers analyse, design, code and test their projects so that I could give a relevant talk. It turned out that what they were doing was naturally very close to agile development and the whole talk would have been a waste of everyone's time. I just gave him the link http://agilemanifesto.org and ended up talking about XSS.
And yet I've seen "agile" teams waste more time in "agile" meetings than in anything else... except for PingPong.
And this is why nobody who is a real engineer should ever take most software engineers seriously.
Well-written software (i.e. clean code, clear functions) is great and a joy to work with, but is absolutely not a substitute for documentation. Public APIs are double-triple-extra not exempt by merely being well-written, especially not C/C++ APIs, which have complex meta-details like "is this thread-safe?", "does this allocate memory?", "can I call this twice using the same object?", etc.
I get that if code is clear enough, it should be self-documenting. That alleviates the need to write as many comments. //Comments//. It's not a user manual. It's not an explanation of architecture. It's not a help guide. It's not an example of how to use it. It's not best practices. It's not how to write a plugin for your system. It's not an explanation of why the software is needed or where it fits into the business's plan. It's. Just. Code.
I've inherited enough undocumented code to take new stance: if I quit tomorrow and people are unable to train a new person to fully understand my code without me to train them, then I'm doing it wrong. "Wizards" are also liabilities.
The code should be able to provide you with the how and the why (supplied with proper testing that covers planned use cases, and comments when testing and code are insufficient.) When code is well written it will answer a lot of questions, I encounter this almost daily when reviewing code.
What code is not is a manual or instructions on plugin writing, etc. You are right on the money there. It's also not API documentation, again, right on the money.
The best-factored simply-named controller source or whatever else will not, in isolation and without documentation, ever tell you why we are asking the computer to do the things it does.
The problem with this is that somebody (rightly or wrongly) will see the code one day, and infer what they think it is doing, and change it, and break things elsewhere in the world.
If you don't want that to happen, you are forced to only ever write code that matches the exact logic of what already exists--and because you, rockstar ninja cowboy that you are, don't have any documentation including business use cases or logic for a particular hack or inelegance, you must then look on and only make the mildest of changes to the sacred monolith.
Or, you know, you could document your projects and software like a real engineer, and others can later check that they can make changes with impunity--or even better, throw away chunks of unneeded code wholesale because their time is (according to the docs!) past.
EDIT:
This whole "The code is the documentation hurrrr" meme is really annoying--it can only express the hows and not the whys. There is more to software than simply the steps the computer takes to transform data.
If there wasn't, we'd still be using assembly and Perl every day.
And yet, non-devs are the people that talk about going to these Agile conferences. They're also the people targeted for Certified Scrum Master certifications. The movement of Agile away from developers has been happening for awhile. It's just another management philosophy now.
Does it matter that the people creating the software are no longer at the table.
Yes. Full stop.
All in all, I feel that the author is simply answering his own questions.
No, its not. Its a management buzzword now. It started as a philosophy, and where it still is, the substance of its principles remains important. But, increasingly, its become a meaningless phrase that marketeers that neither understand nor care about technology slap on snake oil to sell it to managers that are out of the day-to-day process of technology.
To expand on this a little -- members of larger organizations have succeeded in neutralizing a threat to their perceived interests by making the language mean less than it used to. Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
I think that looking at it as threat neutralization is badly misleading. I don't think management saw agile as a threat and neutralized, I think (1) management saw it as something that was producing value that they wanted to harness and implement, but generally failed to understand, and (2) people selling to management recognized this demand, and slapped the valuable label on whatever they could package. No threat, all opportunity. But same net effect.
> Effective agile practice breaks down a barrier between people making decisions and people doing the work. That must feel like a threat if your position involves little more than politely instructing other people what to do.
Honestly, I think that that the subset of management that understands agile well enough that they could feel threatened by it if they couldn't find a way to profit from it is the same subset that understands how to let it happen and own the results. The one that would be threatened by it if they could understand it well enough don't.
I like having a rate limiter between me and the people who keep changing their minds about what I should be doing. I like being able to outsource the job of talking sense into those people.
Yes indeed. There have been many times when I've been explicitly forbidden to talk to actual users in big companies.
At one place where I worked there were 4-5 big teams with different technology specializations and for every big project we did, these 4 teams had to have a cut of the project for budgeting purposes.
So no matter if there was a need for it or not, youd have BizTalk, or SAP, or SalesForce or whatever inject themselves into a solution and create a complete mess from an architecture standpoint. Completely idiotic.
Right on the money I'm afraid.
Really sad that at the end of the day "Agile" meant more admin work and meetings and no noticeable improvements (to me). Of course management saw "improvements" but the "scrum masters" would just tweak numbers to make it look like we met deadlines or completed enough story points. It was really sickening to watch everyone pat everyone else on the back for doing a good job when I knew at least 1/3rd of the scrum teams didn't get close to what they were supposed to accomplish.
Conversely, at another employer they pasteurized "agile" into their own canned "agile-fall" methodology that had many antipodal theoretical conflicts, resulting in just 4 week single iteration waterfall sprints. The results of said agile-fall were very lackluster as no one was empowered, and there no greater clarity into process for dev's.
As such, there is certainly a right and wrong way to do agile. I'd say too many companies fear it because it let's the patients run the asylum (dev's) and reveals that you really don't need so many PHB's.
As the groups mentioned in the above comment have shown a stronger presence, even more people from these groups appear. And, as the number of developers has dwindled, there has been less reason for others in their profession to come and share.
Oh! And also, Lego. I'm a grown man, come on!
The last thing I feel like doing is sitting in a conference of non-technical people talking about how some new funny words they made up in project management will fix everything. Scrum masters, vendors, etc... it all just doesn't really engage me any more than talking about concurrency gets a project manager going.
This isn't to say that I don't think PM isn't important, but just that it really isn't a terribly interesting problem. I haven't seen (personally) that many scenarios where some new trick from a PM book, class, conference has actually made the difference in a project coming in on time/budget.
I personally like a lot of Agile stuff, but I don't strictly adhere to any specific one, nor do I want to in a small team. I just want to produce good code.
Obviously this.
I suppose I might attend an agile conference in the unlikely event my employer desperately wanted to send me to one. Even then I'd probably try to discourage them from the notion in order to get the money spent somewhere more productive (technical conferences, specialized training, etc.)
The daily meetings usually turn into daily status meetings, no matter how much the Agile advocates claim otherwise. The rough estimate become a hard deadline, with daily remainder of why it's slipping. Pair programming - free training for junior developers, a waste of time for senior developers.
The fact that you consider training a waste is depressing. Good senior developers recognize that training is critically important unless they want to do everything personally – and it's extremely rare that you don't learn something, too. If it's a waste of time, you're doing it wrong - a truly senior developer would learn from that and fix something.
As the employer-employee loyalty culture has been systematically destroyed, I am far more likely to see the training of more junior developers as training my own replacement than as improving the capabilities of my team.
If you want me to train someone in anything, you really ought to make me feel secure in my position, such as by offering me some form of job security. For the sake of discussion, let's just call that "tenure". If I am an "at will" employee, the only form of job security at my disposal is to be indispensable, and training others undermines that.
So if your company has a clear career path, with employees from entry-level tenderfoot to ultra-senior guru, and every step in between, you might feel good about training. If, on the other hand, your office is full of young bros, and the dusties are encouraged to move out to pasture when it's time, your time is coming.
If a company truly has a commitment to training, a necessary prerequisite is a commitment to long-term employee retention.
There is very little inherent to pair programming in itself that can be considered good or bad in isolation from the people using it. Good teams follow good practices. This is not because the practices are good, but because the team finds them to be temporarily useful to meet their specific needs.
If your manager went to a conference, learned about agile stuff, and returned to institute pair programming, you will likely find that to be of dubious value. If your team decides internally that the new hire should do pair programming with each of the existing team members until the greenness fades, that will probably have a better outcome.
I'm all for training. I'm against 8-hour a day, 5-day a week pair programming. Even if training is so important, developers are not signing up to be a professional trainer.
(2) The only relation anything "Agile" has to do with manufacturing is that the Agile approach to software is close parallels to Lean methodologies in manufacturing (which have circled around to create Lean software methodologies.) But Lean, while it is an approach to improving productivity, is pretty much the opposite of doing so at the expense of the creativity of the line workers, as they rest on the combination of defining and measuring value and harnessing the deep knowledge of the workforce to propose, implement, and test methods of improving value produced.
I've actually been on a team that did this. "For the next two-week iteration, we're going to change the process in this way, and we'll see how that works."
Process doesn't have to be a static thing handed down from on high. Hack it. Make it work for you. (One of the agile approaches to software is "pay attention to pain". That is, when it's hard to change the software in some way, that's telling you that it should be refactored so that it quits being hard to change it in that way. Well, the same thing works for process. If the process is painful, pay attention. It's telling you that you need to change the process.)
Yes, that's exactly what Lean in software means (and you'll note that it has a very close relation to Agile principles -- Lean is pretty much Agile with more focus on measurable output and several decades more of development behind it -- both for the good and the bad [there's a lot of depth in the literature of practices and how and when they work to draw from for your circumstances, but there's also breadth and depth in the buzzword snake-oil].)
Practices like continuous integration and unit testing traditionally fell into that category. I would say these days that writing unit tests is so common that it doesn't feel like it came from anywhere. Just that it always existed.
The ossification of Agile into a set of cargo cult practices divorced from the particular teams and their needs flips Agile into exactly what it was a reaction against.
In my experience the main thing to keep in mind to improving any system is to:
1. See what state you are in 2. Figure out what new state you would like to be in 3. Guess at something that will help you move into that state and then follow that guess. 4. See if that move helped you get closer to that state 5. goto 1
People label those steps with lots of names depending on what industry they work in but in the end that is the easiest way to get better.
I disagree. That's not how you build a team. Also, senior developers who can't pair program, aren't senior developers. That means you can't communicate, or at least you don't want to, even if it's talking about code you don't want to. That's not how you become a lead/architect.
Ah yes, the cliched "if you don't do X you can't call yourself Y" shtick. I know many senior developers that don't pair program. Why? It's inefficient and they get significantly less done. Not to mention, you have no room to experiment with different approaches because you've got some person sitting next to you and human emotion kicks in and they feel like they're being watched and judged at every move.
You know when pair programming is endorsed by the senior developers? Root-causing bugs.
I can communicate very well, and am helpful as I can be when people need it. But slow-as-molasses pair programming with an 8nexperienced junior sounds like hell to me.
One can be an effective leader, communicates well, designs and architects large system, mentors junior developers, inspires them to learn, coordinates development effort, sets up development processes and standards, and develops awesome software without doing pair programming.
Pair programming is not the only and true way to develop software. It's just some passé imposed by Agile advocates.
I like the idea of story points as a tool for communicating with each other about rough estimates. I don't like story points as a source of data for management to put into spreadsheets and use in dubious "velocity calculations". I especially don't like the results of those calculations being used to measure my individual productivity and set expectations about my future work rate.
The language of agile has been co-opted to suit the needs of mediocre managers.
There's only so much you can charge someone to tell them, "The skills your developers possess for creating and modifying computerized systems can also be applied to organizing software development teams. Just make it part of their jobs to improve their own process, and give them frequent, objective feedback on how they are doing."
One of main obstacles for going Agile has always been that it really needed all of the organisation to change, not just the developers.
Also, Agile conferences aren't really that interesting for developers anymore. We've already adopted most of the development practices to the point where many developers are no longer aware that they came out of, or at least became mainstream because of, the Agile and XP movement.
Most of us are Agile without being aware of it, which in turn leads to hilarious anti-Agile rants (based on experiences with top-down enforced cargo cult "Agile") in which the authors propose alternative practices that are typically Agile and tick all the boxes of the Agile manifesto...
The hard part about Agile is still adapting the entire organisation's processes, which generally is of more interest to management-types than to developers.
Finally, you would be surprised to learn how many people that are active stakeholders in software development processes only now start to learn what Agile is.
For most of us, in our fashions and fads driven bubble end of the industry, Agile is already passé, but for many it's still a revelation.
Both got a bit overdone (Java: everything must be a method of an object!) and hijacked by the Certified Formal Methodologies people and pointy-haired bosses. People found the limitations of both Agile and Object-oriented - there's no silver bullet after all. The good things got incorporated into the set of good practices (and became obvious and thus not worth mentioning) the bad things are labeled as bad (although some stick with us.) Life goes on.
Agile is obviously a bit earlier in this lifecycle - I believe there are no mainstream object-oriented conferences anymore while Agile ones still exist.
Isn't OOPSLA a mainstream OO conference?
To us, "Agile" is the organizational system that you need to build out once the company scales up to lots of devs, but by that time we are already gone, working at a new startup building new stuff in another tiny team. We don't like the organizational cruft, we just like the process of building stuff, preferably with limited management.
There are things for scaled up Agile development such as SAFe, but it's really a hack.
The usual rule of thumb is that "atomic" teams should be 5-9 members (often expressed as 7 plus-or-minus 2), with larger groups as teams-of-teams. Larger teams simply don't work as single teams, and there's centuries of experience supporting that in pretty much every field everywhere.
SAFe is interesting because it can help show large companies understand the value to using XP practices. Crazy ideas like unit testing your code.
My own experience is that 12 people works great for an agile team, with 6-8 of them being programmers. If you're not using pair programming, cut those numbers in half.
If you are interested in hearing about some of the current research that we are doing about team size you can check into it on this video. I am not sure he is ready to publish his work but this can give you a taste of it.
http://www.youtube.com/watch?v=9Trgz2SAz0k&list=PLSRf1YEPZ7u...
Naturally, things tend to fall apart when the spec isn't accurate, or when an estimate is off. In a client-facing business like an agency these approaches often fall apart when the client isn't getting something when they want it.
I've interviewed at a number of large agencies and it all seems to be the same. Everyone does Agile...kinda. They have the general feeling down, but they all skip some parts to make it usable for their clients.
This brings me to ask, does anyone REALLY do it properly in an agency setting? If you do it properly in a client-facing industry will it fall apart, or are people just too lazy to fully embrace Agile? I'm yet to hear of anyone doing it well, but I would love to hear from someone that knows how to do it well in a team of 15-20 people containing developers and Project Managers.
The best discussions I have about Agile happen on the internet or at a programming meetup for languages, databases, etc.
So, in a stroke of mutual back slapping, everybody embraced the less objectionable features of agile methods - daily meetings, short iterations, reduce documentation and focus on shippable code - thus feeling really good about themselves. This caused ample moral licensing, letting most development team members and business people cut down on the unpleasant aspects.
This collective ball dropping was fortunately mitigated by a surplus of employees happy to pick up this poor, unloved ball. Being orderly people they would suggest improvements to the process to prevent further ball dropping, carving out a place and title for themselves while they were at it.
Last weekend I attended Startup Weekend event, looking to have fun trying to build something fast from a simple idea pitch. First day more than 80% of the crowd were business / marketing peoples. Designers were scarce and half of the few developers disappeared during the second day. Maybe I’m a masochist but decided to stay until the end, I figured I’d learn something about the agile event fauna. And I did: in most cases the agile methodology is stepping on top of rational thinking.
Do before you think and fail fast is good, only when you know how to do.
Last time I was on SW I had a lot of fun, but last weekend’s experience was somewhat sad. Gurus and their new methodologies might have some to teach, but will never replace rational thinking.
You'll see this sentiment leak out when discussing the necessity of domain modeling or testing in a mature web app that continues to grow. There's always a contingent that shows up loudly complaining, "but that looks like work! I don't want to!" They believe they have to always be kowtowing to Business by constantly shipping features and patching over what breaks.
As michaelochurch likes to say, we've been colonized by businessmen. Our own ideas about productivity and quality are slowly being replaced by theirs.
I've always wondered if our Devs know Agile practices already, learn it on the fly, or dont care. I am going with the latter.
I apologies in advance if this comment is not to the satisfaction of the community. Just my (possibly bitter) two cents.
IBM has already thrown their weight behind the DevOps buzzword. It will probably be harder to mess with than traditional agile was.
That was one of the things that makes small startup teams powerful. They spend very little time talking to people who are not empowered to make decisions.
[1] If they could understand development, they'd be developers
But to be a project manager or scrum master all you need is a chance, that's all you need, a chance to do something you don't understand, you don't know how is built nor how it works, later you can show up in conferences and training sessions (paid by the company of course) to try to improve your performance/understanding in your current position.
Knowing that, is hard to show up in some events, conferences and meet these bozos.
We do TDD and run our projects through ticketing and a CI server. Once those policies and technologies were in place developers pretty much stopped caring what agile was.(that doesn't imply we don't do it we just don't really worry about the logistics of it)
I sort of think of agile as a interface language for management to interact with us.
The problem remains that managers in most companies cannot reliably discern the difference between valuable work product and the physical evidence of completely wasted time. They cannot tell at a glance whether the code and/or architecture is museum-quality or DailyWTF fodder. They cannot tell when the entire development team is colluding to implement mortgage-driven development. The fundamental flaw in the system is that managers and developers do not think in compatible ways. To the manager, a developer might as well be an alien, asking him for more cows and sharper scalpels. To a developer, the manager might as well be an alien, asking him to drop his pants and hop up onto the Probulator.
What is really needed is someone with both pointy hair and a neckbeard, who can translate easily between the people who need to cover their asses and justify their own existence, and the people who need both rational objectivity and aesthetic merit in their work. Both sides are needed, because honestly I have known too many co-workers that cannot seem to fathom that they don't get paid unless the work they do can somehow add value to the things the company actually sells to people outside the company.
The artist usually doesn't know when to sign the thing and ship it to the gallery, and the gallery salesman often has no idea what the piece is actually worth when a customer shows up to make an offer.
For our organization it doesn't seem to be, and my purely unscientific observation would be that getting devs on board is more about tools and channeling them through a process. That, you can get someone through pretty quick because its primarily logistics based.
We have tickets that are tied to pull requests you have to submit your PRs for test tickets before you can submit your PRs for feature tickets we have a CI server that will run those PR's against the tests at which point we merge everything.
This makes it pretty straight forward how development has to get done.
Where as, getting people who aren't code driven on-board requires complex paradigm adoption about how we design projects and road-map the business. Some of these people end up at these types of trainings because they are the people who need the indoctrination the most.
Developers we have faced have a tendency to either just sort of shrug and go "ok" or to want to totally fight the system and tear it down and replace it with X. We do our best to weed the violent opposition types by using test writing as examples during interviews the violent opposition types usually get visibly frustrated by the "test then code" approach of TDD so we haven't had to much trouble identifying people like this.
The long and short would be:
I think that the thesis of the OP that lack of dev's is a problem can be rejected because engineering unit employees don't face the same hill climb to adoption that business unit employees do and that this has been enabled by the fact that:
developers have at this point written them selves tools to automate their own side of the paradigm... i.e Jira Github and so on
1. Some developer who thinks they understand security, but really doesn't,
make some vague sketches on a napkin that describe how one particular
attack, which isn't even that big a threat in the first place, could
conceivably be prevented, if the attacker cooperates well enough.
2. Development happens without regard to the napkin.
3. Flaws are fixed one-by-one as they are reported with little thought
given to whether the reported flaws reveal a systematic problem.
[1]: That caveat is important, please do not reply as if it is not there.
The article does spark some interesting debate though, also about TDD.
That way, people who want to do real work can concentrate on it without worrying about power games. Power games become pointless, because the power structure is set to stone. That's why democracy is so effective system - it lets you focus on the job, without the stresses of not having any power. Because you can have it, when you need it.
It's only in more recent years that the programming focus has been stripped away.
It's interesting to see how negative news about Agile are being censored.
Nice idea, shame about the religion around it.
Into the cloud, perhaps?