Friday, August 29, 2008

Software Development Myth #3: My Development Velocity Is Based Solely on Me

One of my managers in the past used to say that every developer has a factor that you multiply his or her development estimates by to get a "more accurate" estimate. Ok, I believe this - some developers tend to be opptimistic in their views of how quickly they can get things done - others tend to be more pessimistic.... I even had a co-worker who thought he gave "more accurate" than other estimates...(yeah, right).... so bottom line is there's a sliding scale that you probably fall on as a developer with regards to how optimistic or pessimistic your estimations are... (I won't try to dive into the psychological reasons for how you arrived there -- anyone else want to take that post? :))

But this manager was only concerned with the developers in his environment (not surprising)... however, there is another factor to enter into the equation - and it relates to the organization - and how a particular developer relates to that organization...... so to simplify - the factor that this manager shared about is not simply to be defined by the estimating practices of the particular developer... but also how the developer works in the larger context of the organization.....

For example - at one job - I thought I had honed my estimation skills - working in a particular environment with small, packaged deliverables, and management focused on keeping hard deadlines... yeah, I could narrow things down to almost every line of code I would have to write to make something happen - not taking into account much back and forth with the folks that were requesting it........definitely easier to estimate, and it definitely pulled me from the "pessimistic" side that I tend to be on........then I worked at another company - where there was a little more back and forth - a little less rigid with regards to requirements....so my estimates probably bounced a little more toward the pessimistic side, to compensate for that.... and in yet another organization - a massive organization with many, many parties to deal with and negotiate with - I found my estimating to be on the optimistic side....and it shifted to more pessimistic, to compensate for all the challenges bringing pieces together....

I'm sure anyone who's been in the industry for any amount of time has seen similar sort of pattern... but it's something to keep in mind if you have to make a move to another organization....time moves differently in different places..... :) And you don't usually know the arate at which it moves until you have existed in it for a little while..........

Tuesday, August 19, 2008

The .NET Dilemma

So there exists a bit of a dilemma in the .NET world ... having come from the Java world recently, I think I can probably see it a little more clearly than others.... it is this:

you must use only microsoft tooling, even though it is ages behind the rest of the world

Let me give you one of a few real-world examples to kind of explain what I mean -- let's start with the "you must.." part...............I'm currently doing web apps with C#/ASP.NET - and I would have liked to use an MVC framework...HOWEVER, Microsoft's is not done yet - it's on preview 4 or something... so, the other option is to use Spring.NET or another third party MVC framework... the only thing is: I know Microsoft is working on a MVC framework - and when it's done - they'll make sure there are no competitors - that means there's already a ticking clock on the lifetime of Spring.NET and any other third party projects.... so that's the "you must" part - there's really no realistic choice other than to wait for Microsoft's stuff - or just to not worry about your application becoming *legacy* as soon as you write it.....

Ok - next part - ages behind the rest of the world -- that's right - Java (among others) has had MVC frameworks for a number of years now - they're a well understood thing - they're helpful - and darn it they make you more productive..... why is Microsoft JUST now developing something? Who knows - all I know is that it's way behind the times......

Anyway - that's the dilemma in a nutshell - the fact is - the .NET environment works just fine -- but if you want leading edge power and flexibility -- mmm.. I donno... :)

Thursday, August 7, 2008

LINQ to SQL!! Key Conflicts

Ok all - just a cautionary tale... if you see anything similar to the following when working with LINQ to SQL, consider what I'm about to tell you...

"Cannot add an entity with a key that is already in use."
or any other message about conflicts or whatever.....

I've had this problem probably four times, and for some reason, the symptoms still fail to trigger my previous memories.....and btw, there seems to be no tooling around how to figure out what data LINQ is talking about when it makes claims about bad primary keys,etc...(if I'm wrong, please let me know..)

Anyway - I use SQL Server generated identities for rows... and if that is not annotated on the LINQ to SQL generated code, it will not use the generated key - it will assume the key you are giving it is accurate (be it a 0 or null or whatever....)

So just remember this...... it's annoying....and it's probably, overall now, cost me a week of dev time for this project.... BOOOO


:)

Till Next Time...