Maximum PC

I have a tendency to help people find jobs, I think of it as 'Paying it Forward' as others have helped me find jobs.

This means that I read a LOT of HR postings, and there were some interesting observations I noted. I've been in the industry for 5 years and by no means an expert, but I'm sensing that programmers are very idiomatic, maybe even axiomatic, in our thinking. I see job postings with so many terms that it makes my head spin, and then joining these companies, there's the corporate culture and the work culture.

There are some things I've noted, having talked shop with my programming buddies, it's interesting to see how programmer culture has shifted in the last 5 years.

- A lot of companies have code competitions; programmers stay late into the night competing against each other developing new techniques, new practices, new tools, etc.

- We've introduced Agile into management's vocabulary but as our default software engineering practice. Agile removes a lot of frills and creates a client-centric scenario for the developers whereby the developer and the client interact.

- The developer world is becoming more and more bottom driven as opposed to before when it was top driven. Management doesn't play a huge factor into the equation as developers dictate the type of work and environment.

There are some interesting points I see here: Traditional Software Engineering Practices (TSEP), while boring and stuffy, usually accounted for less hours in the office. A lot of companies (even after their start up phases) that retain the fast paced developer culture has high burnout rates. Coding competitions are great, but what good is it if developers are working 12 hours a day and burning out quick? I noticed that even though developers have revolutionized HOW we work, we haven't done much to address the real problems in our industry which is burnout. Also, I look at how developers implement culture and there seems to be no room for creativity. It's almost axiomatic; developers are so anal about how the environment and culture is supposed to work. It HAS to be SCRUM, it HAS to be Agile, it HAS to be this and that.

I guess it's just a random observation, I'm still working on this theory and maybe I'll write a paper on it one day.

Ive seen arguments for Traditional(What i call Software Engineering) and Agile.

As a student i can only speak for little things obviously

Agile seems great for certain types of projects, we had a class that had a semester long effort for us to implement the strategy and it works well for the little projects we have done(GUI's). You get client expectations, you do an relatively fast dev cycle on it, then you go back to them with your own suggestions and get their revised opinions, rinse repeat.

However i have heard several talks from Software/System Engineers that explain very clearly that certain things cannot be subject to iterative or elastic development. The examples we were given were security/safety critical applications or DoD projects which involve collaboration between the software and hardware sides of the project(missile guidance), preventing each other from changing drastically. The last talk on this topic was about a year ago so i am fuzzy on it, but the sentiment was against free form development seen the Agile manifesto and the rigorous engineered alternative was thoroughly supported.

I hear the burnout story going across most STEM disciplines, which is why many folks are anticipating it by getting minors in business.

Just don't force your team to do more than 50 hours a week- best way to dev something possible.

Your observations are astute young squire. Agile is fantastic for a lot of client-driven apps where the scope tends to change. Traditional software engineering practices (TSEP) tends to frown on scope creep but it eventually happens. I've yet to work on a project
that didn't have scope creep.

I guess that's the point I was getting at: 5 years isn't a long time in this industry but I've worked both small and large firms, talked to a LOT of developers and worked in small and large teams. It's almost anecdotal that when discussing our industry with other developers, a lot of the things that are being talked about become axiomatic or prescriptive. Once, when I worked for a bank, me and my team engaged in an hour long discussion about the merits of Agile v. Waterfall. I guess in 5 years, the one thing I've learned is that do what is best. One of my axioms in code is 'do what is best while maintaining sanity' that is, implement it the best way you can while maintaining readability. I try to apply that same axiom in the way I deliver products.

I don't like Agile. At least I don't think I do. I don't think cranking stuff out that quickly is a good idea. I like sitting down with the client(s) and a spreadsheet (usually printed before the meeting) of a list of bugs and enhancements. We pick a list, talk about priority, talk about what has to happen, maybe some more detail around the issue/item. I go back, I look at the code and make an estimate. They approve my time estimate, I do the work, maybe putting out a test release 2-3 times during the quarter as I finish items.

There is a bit of "scope" creep but for what it is worth, it is usually another small bug that they find in production while I am working that takes me 15 minutes to fix. So I do it.

I like Agile because it keeps release times short and allows me to reign in on work needed. Agile really does help with scope creep, and I like the iterative exercise because the more I interface with the client, the more I really get to know them. However, one thing Agile was supposed to benefit was maintaining sanity in the shop, however, I found that all Agile did (and it's pretty true in some shops) is that while the time frames are short the amount of work doesn't fit the time scale. So developers often work more hours to make deadlines - I thought Agile was supposed to help with this? I guess it doesn't.

I'm trying to turn my one-man team (i.e., me) into an Agile shop but a lot of stake holders in my company are afraid of change.

Agile isn't about speed. It is about building incrementally and moving forward when your base is properly built and tested. It is about allowing flexibility in your design so that you can adapt to unforeseen issues as you build your app and it is about ensuring transparency and communication through the process.



Agile does this weekly with the team rather than the client. Smaller projects are easier to test, easier to track and much easier to estimate.

I've worked in both environments (waterfall and agile) and as a dev, I preferred agile. As a techwriter, I much much much prefer agile.

However, in the end, it always comes down to your team. An improper implementation of the best strategy is worse than a good implementation of a poor strategy.

That problem is solved by proper time estimates. If a dev states they can finish a task in 8 hours and it takes 12 .. whose fault is that he works an extra 4 hours?

Well, 'fault' is a strong word because time estimates require experience .. it takes time to learn how to properly estimate the complexity of a task.

Agile helps with this because it is much easier to estimate the time required for a small project than a large one. A large project has more hidden problems and unforeseen issues that are more apparent in a small project.

Dr. Boehm is arguably the most significant contributor to the field of software engineering (and I'm not just saying that due to the USC connection). He was the head of Software Engineering for DARPA and has significant say in the defense industry to this day. One of his achievements, the spiral development model has actually been used successfully on a number of DoD programs. Of course, this is typically when the companies are FORCED to use something beside their own software processes (ie Waterfall expanded to no fewer than 18 Word Docs and 2 or 3 MS Project files).

Think about what they told you for a second. Only a DAMN FOOL would believe that they're going to get something as complicated as a missile guidance system right on the first iteration... or even twentieth. Of course, this won't prevent the managers, tech leads and software team from adopting the Waterfall system for development! This is the software development model used on 90% of DoD projects. The simple fact of the matter is that software engineers at companies like BoReing are typically much more interested in writing large Word documents than doing real engineering (ie thinking hard about hard problems). They'd rather spend time fixing a TOC and finishing their MBA coursework because very few of them have any real engineering aspirations. Concerning the hardware/software interface, what almost always happens is that someone takes a guess at how the design should be done. They get it wrong. Of course, everyone is behind schedule. No time to change it now... so just write your code around this bug. Just flip a bit here or there, add a couple of magic numbers, do whatever it takes to make it seem like this things works.

Really?! I've never seen or heard of a code competition nor have I witnessed a move away from management having a role. Is this occurring in small companies?


I have a hard time believing this to be the case. After all, part of the rational behind adopting agile methods was that everyone was just too damn burn out working 50+ hour weeks on the traditional methods. Perhaps, I am mistaken about what you are calling TSEP... authoritative managers, waterfall development, top-down design and lots of (useless) documentation. Right?


Are you sure that it is the developer's culture, and not management's culture, that is responsible for the high rates of attrition? If anything, I think the past twenty years can be characterized as a transitional period from fewer, highly technical, engineers and/or mathematicians to the army of programmers style of development. Frankly, I don't think managers care too much about losing a few employees due to burnout because they're whole strategy is based around the insignificance of an individual's contribution. Just replace the fallen pawns.


In this economic climate, I believe this is happening in quite a few fields. Companies are demanding more and more from fewer and fewer employees ... "or else" ... and we're allowing ourselves to be pushed around by these managers running around in monkey suits. What happened to the days when an entire software team would quit the company on the same day and go work for their competitor or start their own company?! We've allowed ourselves to be debased. Just look at the number of people out of work, and we still have execs like Gates lobbying congress for more H1B visas! It is effin ludicrous. Corporations have taken over too many aspects of our society. It is time we restored power to the people.

And sorry about the "scope creep". =)

Concatenating a few posts...


Is the fault actually systemic within the agile development methods? From what I've experienced, most problems usually start at the top with bad allocation and management of resources. Typically, managers have no clue concerning cost/time estimation for software projects and everyone gives a WAG which seems to be about as reliable as using a random number generator.


Well said... bravo. In the case of XP, it is also refactoring bad code, working in pairs to build knowledge, and utilizing automated testing. The focus is on the code, design and algorithms. It isn't about pointless documentation and formality. In my experience, agile development has proven to be far superior to traditional methods.

Of course, the team really is the most important part of the equation. If you can't stand working somewhere or with someone, then it doesn't matter what methodology is being employed.

Small companies and companies that are more developer driven. A buddy of mine works at a firm where they write CRM software for hedge fund managers; they have code competitions once a month. Facebook does the same thing also.



The point I was making (or not making, initially, as I typed this post without really formulating my thoughts) was that Agile was supposed to solve that problem but I don't think it made a difference. TSEP heaved a lot of unnecessary crap (meetings, authoritative managers, top-down designs, and useless documentation) yet Agile, which is supposed to rid of all these things, didn't make it any better. I've seen Agile shops where developers are working 50+ hour work weeks partly because of poor resource and time management,



Somewhat, it's difficult to replace pawns. When I worked in banking, the complexity of our software meant that learning the software took an average of 3 months. You were a SME in two years of working hands-on in the system. Regardless of what software engineering method you practice, developers have to learn the ecosystem surrounding the software and build against it. As complexity in requirements increases, my firm belief is that developer retention should be high.



hehehe, preach on!

Hmm... I'm a bit split on this "code competition". Assuming the company provided me with dinner, refreshments and the atmosphere was light-hearted and fun, I think that I would probably like doing something this once a month. It seems like it might allow some of the younger or better guys to really show their stuff and provide the company with some fresh ideas.

OTOH, if I was already working overtime, not enjoying the job or if these after hour type of things were considered mandatory, then I might be a lot less enthusiastic about it.


This crap is getting out of hand! =)

While reviewing some conference papers today, I came across [url=http://research.microsoft.com/apps/pubs/default.aspx?id=136301]this paper on analytics and software engineering by the Empirical Software Engineering and Measurement Group at Microsoft Research. I haven't had an opportunity to sit down and read it. Just figuring that a few of you might find it interesting. In my own experience, there was a TON of resistance to the use of statistics/analytics to make decisions. I'd rather not get into it because I'm actually in a good mood at the moment. =)

They actually have quite a few interesting videos up on their research site:
All pairs shortest path in quadratic time with high probability
Semi-supervised Learning in Gigantic Image Collections
Understanding the Limitations of Linear and Semidefinite Programming
Formal Modeling with Formula
Variable-Aperture Photography
GeoDec: Enabling Geospatial Decision Making

I know the professor in the last video. He's a really cool guy and the lab that he runs would be a pretty cool place to do a PhD if anyone is interest in geospatial work.

Not trying to be a hater, but this is an interesting post on why Agile doesn't seem to work: http://bit.ly/arAAUz

I'd rather see proof that is doesn't work than an explanation why someone thinks it shouldn't. It has worked in 4 different enterprise environments in which I've worked ... 3 of those had multiple agile teams working independently.

Oh, for sure. From what I have seen / experienced, there is NO way it would work here.

I am sure it works plenty well in other places though. It wouldn't still be talked about otherwise.

Hmm....

Not to be a pita academic who actually reads what people post (including myself), this link has nothing to do with the effectiveness of Agile developement! It is clearly about the incompetence of managers in Enterprise environments, and how they pretend to adopt agile methods.

Just to make the sarcasm extra clear, I'm going to add arrows...

And, for the record, documentation is much easier in an Agile environment if the writer(s) are part of the dev team. This is easier said than done unless you have writers who are trained as devs or have a solid understanding of development processes. However, integrating the writer directly into the team by making them attend and participate in scrums, adding their tasks to the sprint, etc., ensures that all documentation is accurate and complete.

The documentation teams that I've led in Agile environments are the only teams I've seen that have both internal and external docs complete when the code is frozen and sent to QA for release testing.

Note: it is possible that I'm a slavedriver and my teams deliver because I crack the whip .. I haven't lead a non-agile writing team and I'm not interested in taking contracts from companies that don't use Agile dev processes. During the interview process, I quiz the team leads and PMs to ensure that what they implement Agile processes rather than just brag about them.

Understood.

That was part of the point though... it seems everybody thinks it is awesome, but "nobody" really does it.