OLAP?

I got to thinking about my HighBall Project and thought, wouldn?t it be awesome to use some of my know how to wire up some serious cubes and analyze the results from site usage all the way to scheduling analysis?  It?s an idea, but I?m not really sure how I would do it yet.  I do however have some ideas in regards to scheduling and how a nice cube could be used to analyze effective scheduling usage.  Sounds like something TriMet could even use ? if they don?t already do these types of analysis. 

Here?s my thought.

Take a schedule as the time dimension.  That?s simple enough.  Now take X number of routes as opposing dimensions and use ridership counts, peak load, etc as the fact table sums and such.  The data should align accordingly to the apex of routes and concentration of route needs by riders.  This type of data could be used to find out where ridership peaks and drops and how to fill gaps or even where to increase service.

?not really sure, got a ways to go before I try it, but it is an interesting thought for analysis.  Eventually I?ll give it a shot.

Agile is the popular process du jour these days.  Every time I hear "Yeah, we do Agile" or "I know Agile, been doing it for years" I cringe.  These statements are spoken with the idea that Agile is this steadfast, unchanging, unalterable, single process that everyone is following.  It is often spoken without any knowledge of the history of Agile, the people who signed the manifesto, or what the true ideal of Agile is.

Agile is always changing, will always be changing, and we'll most likely all be new to it all the time.  Agile is something that flows differently for each group that tries it, but there are core tenants that must be met.  These tenants aren't part of a "process", but could be, they aren't part of a "method", but might be a result.  The point is, nobody really knows Agile, they know their team.

…or maybe they don't know their team if they think they know Agile?

That is something to seriously ponder.  So how does one know when they're talking to someone who really does adhere to the Agile Manifesto.  This is actually the simple part.  Generally they won't even mention Agile at first, but instead they discuss processes almost immediately.  Things they do to enable the developers, things they do to maintain velocity and keep things upbeat and positive.

Some of the first signs that a shop is truly Agile can be summarized by the answers to a few questions.

1. Does the team always have working software?
2. Can you regress and refactor quickly?
3. Do iterations ending or burn down charts stop velocity?
4. How many hours a week is the average?
5. How often does the team have to work excess hours?

…and one of the most important questions of all…

6. How often does your team get to speak with customers?

Does the team have working software?  If it doesn't, it's probable that they are not Agile, or not quit Agile yet.  A team needs to have working software.  The only lgeitimate excuse I've ever heard is, "we started yesterday and are a few days away from working software".  But even then, there should at least be some paper prototypes, or discussion notes with the customer about the proposed working software.

Once there is working software, how fast can the team regress and make changes?  How fast can the team refactor?  How often is the technical debt paid down?  This is a major sticking point that I hear a lot.  Teams must maintain testing, regression, and the ability to refactor.  The team must refactor regularly and keep the debt paid down, if not, there isn't a reserve entity out there to pay down the technical debt or provide a stimulus!  Without these things a team is running rough of Agile.

At the end of iterations does the team stop completely, take a breath of fresh air, and prepare for the hike up the mound of progress again?  If this happens, something is definitely wrong.  Iterations aren't supposed to break progress, merely reflect and maintain veloctiy.  This is where I've become more and more a fan of lean style or kanban style.  The hard stop that iterations often incur is very detrimental to velocity and sometimes even to morale.

Speaking of iterations and mounds of progress, how many hours are worked for that progress?  Are the hours consistent and maintainable?  If not, they should be.  Beware the other inconsistency of trying to apply 40hr work weeks to everyone.  Some people can do 40 and some can do 50, the key is to maintain velocity and maintain morale.  If one person does 50 hrs per week, great, make sure they're not burning themselves out.  Make it easy for them to maintain that.

The customer?  "What, we have to pay attention to the customer?", is a statement I heard recently.  I can't help but just look down whenever I hear this, at least when it is spoken seriously.  The development process and software process should NEVER get disconnected from the customer.  The industry as a whole learns this lesson over and over and over again each year.  We should all now know, we must stay in communication with the customer.

With all those thoughts, I leave this entry with a question for everyone, "Is your team really Agile?"

In my humble opinion, as long as a team is working on acheiving and getting these key points in place, all is good.  If not, the team should probably reflect a bit on what the end goal is.

http://colorschemedesigner.com/

With the recent upgrade the ReSharper 4.5 I’ve noticed two MAJOR things.  The first is that the speed is much improved.  This is a big plus when I’m on machines that can always use a little bit of a boost. 

However the other thing that has been added, which I very much enjoy, is the fact that I can use the ReSharper Unit Testing Interface now with mstest.  This has been one of my biggest frustrations with mstest (aside form the fact that they’re slow, awkward, aren’t as feature packed, etc).  I still prefer NUnit, xUnit, mbUnit, or some other framework more than mstest but at least mstest is tolerable now.  Mstest is used in many shops, so now it won’t be as painful and slow to step into development in shops that use mstest – I’ll be rolling ahead full speed now.

On completely different topics…   code, code, code, code, code…

One of the things I try to do is to find parallels in my personal software development, professional work related development, what people are looking into currently, and then I try to wrap them all together.  Sometimes that means writing blog entries to increase knowledge about something or just hacking out a quick example or implementing a full application to implement for a client.

One of the applications I’ve used recently, HighBall, is a combination of personal motive, work related effort, and a combination of other things rolled into one.  As I work through its build out I’ll probably shift gears and priority a number of times.  Needless to say, it’ll be a bumpy ride for sure.  However, I do intend to keep it up and maintain a flow with the effort.

Some of the other work that has come up is parallel threading and processing.  This isn’t a high priority yet, but it isn’t a low priority either.  Work demands have encouraged me to look into processing, scaling, and wide horizontal scalability.  My interests definitely lead me to this type of knowledge expansion, so expanding it, it will be.