For efforts were I've seen Agile, a good close to true Agile Process in place, I've seen solid progress and generally good success.

Everything else has generally been a complete failure.  Schedules aren't met, money objectives are screwed up, projections are lost, quality is crap, and the list goes on.  When I say Agile I don't mean pair programming, or scrums, or reducing defects, or any of that.  What I mean is a good solid mix of ALL those things.  Without measurability, without continuous integration, without solid developers, without some pairing (i.e. at minimum regular communication), without daily stats/scrums/stand ups/or whatever one calls em, with defect reduction, there really is not progress.

For the life of me, I cannot figure out what the resistance is to Agile Methods.  I understand there is this whole bandwagon issue, that people tend to shy away from bandwagons when the posers start pushing the ideas.  But I must say, look past the hoopla and find out what Agile really is, read about what the processes were designed to combat.  There is a reason they exist, there is a reason why these methods are better in almost every way than anything else that has come up in the industry.

If you can't join an Agile team, read about them.  If you can't run an Agile team, read about running them.  Eventually you'll find yourself in better shape to get into or run an Agile team.  You'll also find yourself becoming more and more of an advocate for the specific processes, ideas, and the intentions behind what is outlined ever so simple and eloquently in the Agile Manifesto.

…

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

…

On that note, we developers have recently fallen down more over a few of the key elements here.  Customer collaboration and responding to change have taken a back burner priority lately and that, simply put, sucks.  We've slowed because of it, mind you, we had to back track on design and implementation for some major pieces of the application with refocused us on working software.  The problem is, we inherently missed interactions and iterations because of it.

Basically we've slid right off of a solid path toward a good Agile effort.  We're working to get it back in line and I need to tighten the belt and quit being a slop about it.  The developers, including I are primarily responsible for making sure things go well and we need to get back to that.  We need to make sure we get back on iterations, we need to make sure we have the collaborate and the good response to change.

Over the next few (that's 3) weeks we'll be getting things back on track.  Just a minor derailment, no train wreck at all really.  But here are some bullet point items that we're planning on doing to get moving faster once back on track.

• Brown Bag Lunch – Basically we're planning to cover topics to explain functional pieces of code that have been built but others might not be familiar with.  i.e. If someone built some cool service factory tweaks, they would do a quick 10 minute description, we'd discuss, eat some good grub, and then commence to refactor were appropriate to properly utilize the service factory.
• Code Review – We started this somewhat, but we need to extend it to some honest to goodness pair programming code reviews.  Doing on the spot fixs, refactors, etc to really get things understood and cleared up so no confusion occurs.  This will also be a good time to get into practice for KISS, DRY, YAGNI, and other checks of that nature.
• Working to clean up and provide a well defined installation file for regular drops for customers/boss/users to play with, test, and provide accurate feedback with.
• Clarify the need, or lack of need at this time for separation of concerns (SOC) past were we have them separated currently.  Along with that we'll be defining better our boundaries around coupling and our acceptance of were we'll be tightly and were we'll be loosely coupled.

…I'll have more on all this, some of the descriptions, conversation points, and other information in regards to the above Agile Manifesto and how it relates to project success.  I also want to, along with another million topics, write up something in relation to coupling…  hopefully I'll get to it all at some point.

CIOs think developers suck.

Developers want CIOs to get a clue about Agile.

Why the CIO is clueless.

These articles are really good, and for a project lead, CIO, developer, or anyone in the industry they should read this.

I have to say I couldn't relate at all to why CIOs think developers are clueless.  In many situations, especially the non-agile, stuck in a silo, non-communicative old school developer the CIO that thinks developers are clueless is absolutely right!

Fortunately though, the new developer is more techno savvy, more communicative, more social, and much more agile.  The way people work is finally opening up and it should do a huge amount of saving the CIO to developer relationship.

Anyway, they're a fun read, check em' out.

Ben_Hall Another great quote – "I would only do TDD or unit testing if I cared about my code quality". – Excellent so you don't care at the moment? about 11 hours ago from web

caseorganic The reason Twitter works is because the question "What are you doing" is never fully answered. about 20 hours ago from TweetLater

deprivation @adronbh premature optimization is the root of all evil -knuth 03:49 PM September 03, 2008 from TwitterFon in reply to adronbh

ahockley Slashdot is a great way to read about everything that was reported a couple days ago via blogs. 03:40 PM September 03, 2008 fromtwhirl

adronbh Software must be developed with efficiently solving the problem. Otherwise the criteria for success is wrong. 03:07 PM September 03, 2008 from web

 

 

ahockley So when is Google launching their own poltical party? Vote for us because we know everything about you already… 01:15 PM September 02, 2008 from twhirl

shanselman All figured out, it was a different terrorist Hanselman, I'm on my way. 12:08 PM September 02, 2008 from Hahlo

I'm currently working extensively on a Windows Application that has a heavy Office Excel UI requirement.  I've done a fair bit of work on XP with Visual Studio 2008 and a fair bit on Vista with Visual Studio 2008.  The following are some of my current rants, about the completely asinine things that have happened with these operating systems and Visual Studio.  All of them, really have zero to do with Visual Studio, it just happens that it is kind of the messenger stuck in the middle of the operating systems and the user interfaces.

The first issue popped up using Telerik Controls for Windows Apps.  Great controls, awesome graphics, etc, I can't really knock the controls themselves and Telerik has always done great work that I've seen, but something occurred that made me question this.  When I pulled the code base on XP I could see the grid on the design time form and all was great.  I then loaded the same form into design time on Vista and BOOM the grid is dropped down below the form on the space where dialog boxes and things go!  This makes it impossible to use the grids in design time while running Vista.  What gives?

Needless to say, NOT impressed.

Another problem is VB itself.  How the hell does one set an EventHandler object to the event?  In C# one just writes:

	 public event EventHandler Shell_Load;	protected virtual void RaiseShellView_Load()	{	EventHandler handlers = Shell_Load;	if (handlers != null)	{	handlers(this, EventArgs.Empty);	}	}		

I've tried a dozen ways to setup the EventHandlers handlers = Shell_Load; line up.

In VB it always starts displaying a compile error, something about not being able to raise the "Shell_Load" event, which it I wasn't trying to do.  If anyone knows how to hook that up in VB I'd greatly appreciate a comment.

With all that said, I'm seriously thinking about jumping camps just to find all the reasons to bitch about Java or Ruby or Rails or something.  At least jump camps just to assure myself it really isn't all that sunnier on the other side.

I'm not 100% sold on it, but it also seems the Java camp seems to have a higher percentage of solid developers. Just an observation based on the fact that many .NETters are just now using patterns and other such notions in development that the Java crowd jump started years before it seeped its way over to the .NET world.

So lean and agile are very similar, for all practical purposes the same thing.  I know this, I've studied them enough to be very aware of the fact.  To this end it appeared funny to me that Martin Fowl, and a follow up by Chris Sims, wrote articles about the fact that these things are so intertwined they are practically the same.

I honestly didn't realize that there was such a gap in understanding, and fortunately have not seen questions such as "Should I use Lean Software Development instead of Agile?"  This really begs the questions, do people know what they say they know?  Why do they speak and question before even attempting to review the premise, basis, and ideal of what something embodies as true?

Now I've come off as aloof probably, which is absurd.  I'm honestly asking these questions because I am honestly amazed at the gap of knowledge by those who should know these things or at least understand they should review the topic before blurting out questions.  The question above, "Should I use Lean Software Development instead of Agile?", could have easily been answered by about 3-6 minutes of reading.  Which would leave a much better impression and understanding of the similarities than someone answering the question directly.

Simple suggestion of the day: READ.

If this appears brash or aloof it is probably because I was up until 3am attempting to fix cluster @#$%ed code.

My brain is cooked, off to code more.