Not sure how many people do or don't get into a good flow at work.  I wonder how many do versus how many don't.  Currently I imagine that not many places have a good development flow.  Instead they have more of the wait, talk, wait, wait, wait, now develop really fast type flows.

I was just brainstorming and attempting to think of a good flow.  So far this is what I've come up with.  Starting in the morning, going through the day of a normal week long or maybe 2 week long iteration.

An agreed arrival time is met, let's say 9:00am is promised by the team.  A quick stand up begins at this time.

Stand up should consist of NOTHING more than this is what I did yesterday (that the group needs to know), what I'm doing today (regardless of what one might think affects someone else), and what I'll plan to get to tomorrow.  Then, after those three quick items, mention the road blocks & concern for roadblocks that are anticipated for the day.

9:15 am IF needed, otherwise don't do this step.  Review burn down chart, priorities, and what other elements of the project will need reviewed for the day.  Identify members external to the development teams and break off for those meetings.

9:20 am Begin individual dev efforts.  I'd prefer TDD style with a pair partner, maybe not to sit side by side, but each do respective work and either swap or mix up each others assignments on a frequent basis.

During the course of this morning work session if user stories are needed, clarification is needed, or any questions come up they should be asked immediately to whoever the primary stakeholder of that information is.

...contextual notes:

In no way should user story meetings need to go over 10-15 minutes.  Long design sessions just mean that information will be lost and these elements will need returned to.  It is better to have working code and product in hand of users than it is to have some fancy design.  At the same time however, in stark contrast to this is the need to keep in mind the architecture.  Depending on were, and in what way, the working code touches other parts of the architecture the design might need to be discussed separately than a user story design session.  Either which way, the overall meeting should NOT go over for extended periods of time.  Design sessions and user story clarification should be quick, and foster communication that is to the point, fact finding, and then production of working code for that user story should ensue.

sarcasm alert:  unless of course you DON'T want a fast moving development effort.

...end of contextual notes:

Noonish - lunch - foodz - sustain life - etc.

Last minute events should be:

30 minutes before departure for the day one wraps up by making sure there are no incomplete work stories in progress and commits all code.  Anything that actually needs to continue the next day needs to be noted for the following day at stand up.  If all tasks are completed the same should be done.

The first and last days of the iteration.

The only exception to the above work flow for the day should be on the first and last day of an iteration.  The biggest difference is user story meetings, clarifications, discussions, architectural planning, and burn down chart maintenance should be done at the beginning of the iteration.  This should be when bug fixes, architectural changes, and other big picture items should be discussed and planned for the ensuing iteration.

At the close of the iteration a clean, building, operable drop of the application needs to be made.  A test deployment and initial regression test should be performed by end of day on iteration end.  The quality assurance process then continues testing for x days and begins immediate bug and issue tracking that will feed back in to the next iteration.

This, is as I see a smooth flow for reaching fast, sustainable, and got morale based throughput.  If anyone has any thoughts on this I'd love to hear were this breaks down.  I've made a an effort to keep this description relatively simple, but would love more input.  Anybody from the peanut gallery?

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. 

I'm not sure if I really wanted to do it, but I did.

http://twitter.com/adronbh

As the saying goes, so do the numbers.  Interesting write up about skills acquisition by experience and how lonely it truly is at the top of the game.  Interesting read if you like the thinking behind the industry.

I dig reading InfoQ, they generally have really good material from top talents in the software industry.  Today I found a chuckle out of the worst and bad lists.  The first is "Scalability Worst Practices" and the other is "10 Ways to Screw Up with Scrum and XP".  The first one I found interesting because of who wrote it, and understanding were he most likely found or experienced some of those bad practices.  The other one is the continuous battle I fight, to prevent Scrum and XP from being screwed up.

Scrum, XP, Six Sigma, Lean, Agile, and any of that lot of practices are easily skewed and bent out of effect.  If you aren't getting good results from the leaner methods you have a two major failure points;  A:  People training or experience might be lacking or B:  People refuse to buy in to learning and moving forward with the technological pieces.

In both cases people could equate to managers, developers, or anyone in the project.  The fact is, it is often the managers that prove the failure point.  If the developers even buy in a little bit they receive major improvements in productivity and the simple tenet of having fun while working.  If managers still stay heavy in process and control, as often managers of the old echelon do, agile, lean, six sigma, and all the other cleaner methodologies do no good whatsoever.

Whatever the case though, pointing out the avenues of failure, the lists of the worst practices, and finding the bad lists in life help us to remove those things in the future.  If we know the failure points, they are easier to avoid.  Hats off to those that know history and can work to avoid the mistakes of the past!

So I was messing around with ReSharper and I accidentally hit Ctrl-Q.  Amazingly I was hovering over the method I had just tossed some XML Comments on.  ReSharper displayed this awesome message with the documentation.

(Click to see the bigger image)

Anyway, you'll notice the XML Comments, method name, and the display box I have all tagged with gigantic red arrows.  I couldn't help but think, "check that out, way easier to read the green XML comments".

Meanwhile a few hours later I was poking around Haacked and somehow stumbled into this blog entry.  Go figure, I'm only 2 years late on figuring out this nifty documentation trick.

...and that makes reason number 234,987,123,203 to GET ReSharper!  Otherwise, you're spending too much time doing whatever you're doing.

Go check it out.  Code Smack!

There are some great shirts.  Namely I'd like to get...

WebTrends

It seems there are flurries of activity at WebTrends again, at least in the local Portland news.  A new CEO, Alex Yoder, a 7 year veteran at WebTrends has stepped up.  Personally, and maybe I shouldn't yap this, I kind of dig the idea.  Alex is a solid guy, knows the business, and is really fit for the job.  Overall, I'm digging the decision of the board.

In other news, WebTrends has torn through another quarter of awesome profits.  This of course means the employees get a little kicker from the company, and I love to hear that - nothing beats company productivity and quality like happy employees.

Bailey's Taproom Round

I'll be hittin' up Bailey's again with my normal round of .NETters, Goths, metal heads, entrepreneurs, and start up peepz.  One of the things I'm contemplating, if I can handle and if it would be worth it, is starting an open source project.  Problem is, what really needs built, what do developers or some particular user base actually need in an application?  The other real question is, who would want to throw in on a project like that?

The Startup

Right now I haven't had time to write up any real tech related topics about what I've been working on.  There have been some significant blockages and rough spots, that we as a team are ironing out.  On the technical front though I think I'll probably have some interesting UI & MVC related topics coming down the pipe.  Otherwise I've been taking it easy and trying to keep focused on productively moving forward without the speed bumps getting in the way.

...and Personally

I've also been trying, still, to get BlogEngine.NET up and running.  The blog engine itself is running already, but the ETL for getting stuff out of Community Server is no easy task.  Rather confusing and frustrating in all honesty.  Once I get a little more time I hopefully can get it knocked out once and for all.  It would sure simplify my blogging efforts.

I've been extra active reading blog entries lately and have come upon a few that have really got me kind of wired.

Software Development Dogmata - Good Practices Gone Bad

The first one is this article by Daniel Pietraru (who I do not know) over on little tutorials "Software development dogmata - good practices gone bad".  There are few major issues I have with this slight skewing of facts.  Overall, excellent article, but there are some issues.

First is the "Agile != Flexible".  Read the manifesto, there is no such thing as Agile that isn't flexible.  The birth of agile that is mentioned is rather skewed too.  If you truly want to learn about Agile, and you have a motivation to have good, happy, satisfied employees that are highly productive, look up the motivations behind Agile.  Otherwise, don't.

Daniel then goes on to negate the benefits of a short development cycle.  Iteration based development has proven so effective almost every major process out there these days takes some form of this.  As for the statement he makes "you cannot demo a car engine until it is fully built" is patently wrong.  You CAN demo a car engine and that is the entire point behind computer models used solely to design engines, and cars in general, in a very LEAN or AGILE manner.  So you can deny it, but I believe these methodologies, the focus on individuals, individual motivation, individual enablement, and other such characteristics of lean, agile, and others is exactly why Toyota has stomped the competition is is basically the world leader in automotive manufacturing and quality.

One really can't deny Toyota's success, and it is the prime cut of what agile is.

Pair programming, he has a slightly decent point on this topic.  I too find myself torn about the usefulness of pair programming.  It does, however have positive effects, but I don't buy into the eXtreme Agile approach to the whole pairing with one keyboard and one mouse.  Working together, communicating, and effectively integrating code into the main continuous integration serves just fine.  But, I can't really knock it either as I haven't truly tried hard core pair programming.

He goes on to slander design patterns, TDD, UML, and a few other things that most developers are fully aware is very helpful in software development.  Not sure why he hates so much of successful software.  I ponder, what does he like about successful software?

In Daniel's defense, he does have some valid topics, just the article is angry and seems to be centered incorrectly and lash out in ways that don't do the points he makes justice.  He does point to a very effective proven use of Agile methodologies, on a massive scale, for a company that turns a little it of profit now.  Google - so read the WHOLE ARTICLE of Stevey's (this guy works for Google and I've read his material several times) and don't be so frustrated with Agile, there ARE good and bad versions.  But I digress, on to the next.

Naming Conventions:  Are They Really That Important?

I stumbled on this entry, I don't know when, but somehow it reflected several conversations I've had recently.  I like naming conventions, when enforced by ReSharper, Intellisense, or something of that sort.  But to remember all, and then have new developers go about learning them all in today's development environment is...

...well...

...an utter waste of time.  Naming conventions are in no way important like they used to be.

Source Control is not a feature you can postpone to vNext

I just thought as I have many times, Microsoft doesn't seem to get source control.  Ayende @ Rahien (the awesome software simian) goes on a slight rant about the absurdity of their solutions so far.

Why are the Microsoft Office file formats so complicated? (And some workarounds)

It also seems that with my new effort to build awesome Office interfaces, tools, and solid back end architecture for these systems I've found the insanity of Microsoft's Office file formats.  I never realized, but Joel Spolsky, who I've read a lot of lately, worked on the Excel team at one point.  He points out that there a more than a few pages (349 in one PDF) of documentation solely about the file formats of Office.

A Field Guide to Developers

Joel also did a great write up in the year 2006 about how to get a keep top developers happy and productive.  Things like private offices, cool toys, a good physical work space, and one of the most important topics being the social existence of programmers.  It points out the importance of having great colleagues, independence and autonomy, how they're treated, and that there are no politics of the feeling type.  As he states in the entry, "And this is the kind of environment you have to create to attract programmers. When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.".  This, no politics philosophy, is absolutely 100% true!

Of only it was more common!

Top Five (Wrong) Reasons you Don't Have Testers

...and an article on why a company, that intends to build good and reliable software should always have software testers.  Again, by Joel Spolsky.

I also dug up another very interesting experiment that the company 37signals undertook.  4 day work weeks.

Workplace Experiments

Amazingly, they got the same out of a 4 day work week as a 5 day work week.  Oddly enough people work much more diligently and effectively when they're able to get a solid weekend of separation from work.  This obviously wouldn't work with every occupation, like for instance McDonalds would probably get minimal amount of use out of 4 day work weeks, but software developers are not McDonalds employees.

Another great article in a similar vein is Increasing sustainable pace.  One of the comments is a classic combination of my railroading interests and software development, "Working more hours may not be the best solution. In the long run, working smarter always wins over working for longer periods. John Henry was the best rail spike driver in his day, and he died proving it. Power tools today let anyone work faster than John ever did.".  I firmly believe that smart workers will produce far more than a bunch of overworked code monkeys.  In my experience this has also been proven time and time again.  This blog entry led me to a few searches, which then led me to some other articles.

That has been my reading for the day.  It's been a ton but I just got on a blog reading kick and figured I'd write up what I've read as of late.

Community Server is costly, elaborate, kind of cool, has a few skins, and blagh blagh blagh.  Out of all these things costly is a big problem.  Of course there is the free version etc., etc, but changing and modularity, ease of code readability, and other related items have caused me to limit what I do or do not build for my web site.  One of the biggest limitations has been the frustrating skins available for Community Server, at least the version I have.

All that said, Community Server is a 6 or 7 out of 10.  I looked at DasBlog and it is pretty decent too, probably a 7, maybe 8 out of 10.  But the one that is uber easy to setup, by far easier than those other two is BlogEngine.NET started by the cool man madskristensen.  This software, even though it doesn't follow all of the particular standards and such that I might have used, is still a top notch and ridiculously easy package to setup.  Especially if one actually uses or develops with VS.NET.  It took me about 5  minutes total, including download time, to get the whole thing setup.

So over the next few weeks things might take a bit of a back burner while I build the ETL solution for getting the comments, posts, and other such infoz from the current site to the future soon to be site.

...so stay tuned.

Ok, I don't really know the guy, except that we both are rather hard core proponents of treating programmers, at least the really good ones the way they deserve - LIKE ROCK STARS!!

But Joel writes up some articles here and there and I find I agree with him on these points too, especially his article on inc.com (and on his blog here).  I'm all for a company being as productive and profitable as possible, as long as they don't lose focus on why they exist (besides to make money and stay in business).  Starbucks is one of those companies.  I love the company, but over the last 2-3 years, with the help of Portland's choices, I've all but cut out Starbucks from my expenditures. 

On that topic Joel diverges from software topics and hits up some Starbucks topics over on inc.com.  So check out the article her wrote, and hopefully Starbucks will be checking it out too.  They really NEED to.

Sure sure, sometimes I still get a Starbucks, but most of my coffee money goes to companies that still get it about product.  The product is king (right after profits to stay in business, if you aren't in business you don't make the product anymore - it is NOT a chicken or the egg scenario) - companies can NOT forget this.

For real service and good coffee, from a place that doesn't need to make up new names for what they do, check out Stumptown.  Truly pwning Starbucks in the coffee arena.

 

...and btw Joel, they're (Stumptown) coming to New York, and I promise if you like coffee they are worth the trip (via Subway, probably the easiest way to get there).