Joel From Canada

Joel Semeniuk's Blog

  • Agile Estimating is great – but you still need good requirements

    David Anderson talks about Agile Estimating.  I agree with all of this 100%.  However, how do you estimate a guess to begin with?  What exactly are we estimating?   My experience has shown that we do a poor job estimating from the start (techniques that David describes in his book and in his blog will help this make us do a better job) – however, what I’ve found is that we do an even worse job discovering, specifying and validating the requirements for which we place our estimates.  It’s like building a building on quicksand.  Yes, yes, yes – agile (I don’t use the term as a noun) techniques allow for changing requirements as you go through your lifecycle, however we still do a poor job with even our root requirements. 

  • Joel is Heads Down in Team System

    I haven’t been blogging much lately, my apologies.  I’ve been crazy busy.  With what?  Team System of course.  It seems that I’ve been doing nothing but for ages.  First off, I’ve been helping to deliver Ascend training in the UK, Amsterdam, and this week Redmond on the Microsoft Campus.  I'm heading off to Hong Kong in a couple of weeks as well - then back to the UK for some very specialized SDLC Process Adoption consulting along with more Team System workshops (a week long set of workshops that I've put together that focuses on making the product do what we need to do in our environments).  

  • INETA and "Me" - on the next Oprah!

     Yay – I’m on the Speaker Bureau for 2005. Wow – I’m REALLY stoked and excited.  Close your eyes and picture a short man who needs to lose some weight dancing (perhaps the Salsa) in his basement office…. That could be me right now…

  • Work BurnOut?

    I’m hearing this a lot these days – burnout.  It’s as real these days as it ever has been.  As a CEO, RD, Father, Husband – I am right on that edge myself – well, I’m actually much closer to the edge than I like to admit right now.

  • Rethinking Infopath

    I have to admit, that lately (largely due to the preparation I’ve been doing for the Smart Client UG Tour in Canada) I’ve been rethinking InfoPath – mostly because I’m finding more and more deployment tricks and integration methods with other blocks and scenarios (For example, InfoPath exposes RegisterSolution that allows you to register a form on the local computer – this could be called by the Updater Block post processing routines for example).  I still have a problem with the fact that there is no Infopath reader from Microsoft – an Infopathlite if you will… and that the deployment of Infopath itself is quite “heavy” without going into the discussion of the deployment of service packs (etc).  But for customers who have Office 2003 and the deployment/update problem solved – I could see InfoPath as being a truly important piece of the Information worker’s toolkit.  What is lacking in so many organizations, in my opinion, is the goo that Infopath needs on the back end – such as BizTalk, well built SOA’s – etc.  Additionally, if you want to have Infopath used offline, you need to jump through some hoops – in much the same way you would jump through those same hoops with the typical home grown smart client app (you still need async submission, guaranteed delivery, queued architecture to do this correctly).

  • Team System Class Designer

    VS.NET 2005 Team System ships with a number of designers, and you should pay particular attention to the Class Designer.  Like all Class Designers, this canvas lets you visualize the structure of classes and types in your project generating source code as you go.  In fact, don’t think of this tool like round trip engineering since changes you make to your code are instantly reflected in the diagram and visa versa.  Why do you want to use the class designer?  Well, you can use it to document or understand existing code (trying to figure out someone elses code bugs me sometimes), you could use it to help take what’s in your head to your screen – and you can also do fancy things like refactoring your code.  What I really like about this particular designer is that it is tied to the CLR where a lot of other designers are strictly UML based.  This designer is even language specific – for example, if I’m in a VB.NET project I get Public, Private, and Friend access levels… in a C# project I get public, private, and internal.  Nice.  I simply love the fact that I can toggle between code and picture seamlessly (did I mention I love making pretty pictures?).    I can also create enumerations, abstract classes, structures, delegates, and modules… and the Class Details window ROCKS I might add.

  • Team System Distributed System Designers

    Lately I have been playing around with the Distributed System Designers in VSTS.   Distributed System Designers are cooked into VS.NET 2005 and is comprised of 4 different designer surfaces;  Application Connection Designer, Logical Datacenter Designer, System Designer, and Deployment Designer.  I can’t help grinning while using them.  I love drawing pretty pictures – I love it even more when those pretty pictures come alive and do something useful for me.  I intend to write a whole whack of comments about these designers in posts to come – but generally speaking they represent yet more powerful tools that will help my projects be successful technically.  They excite me because I think these tools will become as useful as SQL Server’s diagram tool – we always found ourselves creating our models on that surface and as you know the table diagram designer went out and actually created the physical implementation under the hood for you.  Now, there were some DBA’s who were very hesitant on using that design surface because they were set in their ways (which is cool – don’t get me wrong) – and because of this I have always thought that the tool was under utilized.  I find the TS designers fairly intuitive – however, I’m positive that it will take getting used to on real-life projects.  I’ve used them very successfully so far to create and connect my skeleton projects together.  I haven’t, however, had the chance to take it through a full lifecycle on a real project.