<$BlogRSDUrl$>

Friday, October 31, 2003

LONGHORN

The winds of change are blowing, no, veraciously howling, over the lands of Windows programming. The next Windows, codenamed 'Longhorn' has been the star at the PDC in Los Angeles over the last few days, and I can tell you: there are lots to learn!
(Come to think of it – it’s been hyped for a while now).
Thanks to the *massive* (which is what I call two years of hyping up developers) marketing campaign Microsoft has been running, combined with the excellent online resources becoming available on the SDK, we might just have enough time to learn about the new technologies behind it in time for the release of this beast.

Over the next few days I'll blog on the so-called 'pillars' of Longhorn:
  • WinFS

  • Avalon

  • Indigo


  • I'm also looking into Microsoft's next version of VS.NET(codenamed 'Whidbey'), which will be released shortly after Longhorn in 2005.

    (For a good overview, see Chris Sells' article, Living la Vida Longhorn).

    Wednesday, October 29, 2003

    Thought it was quite interesting to know that the biggest solar flare in YEARS are heading towards earth.

    Just my 2cents for today :)

    productivity 

    I’ve been having a brain scrum with myself this morning on measuring productivity.
    Management is faced with, amongst others, the daunting task of increasing their employees’ productivity. This is often not as easy as it may seem.

    The software industry is known to not have any universal methods for measuring productivity of developers. Not being able to measure how productive you are is a problem – how much, and in which areas, do you plan on becoming more productive? You’d never know, without the knowledge of how and where you are productive.

    To measure Lines Of Code (LOC) is simply not a way to measure the productivity of a developer. If I can accomplish functionality with less LOC than you, it certainly doesn’t make me less productive. (It might actually make me more productive!)
    Function Point Analysis (FPA) has been hot for a while, but is in my opinion a mere indication of your productivity. Just to put some mud in the spokes: all functions aren’t equally difficult. To produce one difficult function could be seen as more productive than producing three fairly simple functions.
    I have talked to people who choose to simply measure the Amount of Hours worked, and translate that to productivity. That could work if all your developers are equal in all factors: ability, experience, etc. Not a good way of measuring productivity, for sure. If you produce functionality that took me 2 days, in four hours, you are more productive than me.

    To stir things up even more: there are different languages. Writing a COM component that shows the current time in VB will take less time than doing the same in C++. The C++ coder will likely spend a bit more time on it - should he be seen as less productive? He does get to deal with much more complex programming, and his final product might use memory more efficiently. There are many facts to consider, aren’t there? And this was a simple example…
    There are ways of measuring productivity in software development that I’m not going to discuss here, as this is not my point.

    My point is this: for effective management of developers, use the abovementioned techniques only as measures of indication. Low LOC might indicate laziness in certain cases, and genius in others…

    GET TO KNOW YOUR DEVELOPERS PERSONALLY. This is the only way to know exactly where your potential for increased productivity lies. Take the team for dinner after a successful project. Help and share your knowledge. By knowing your people, you will know what to make of their LOC figures, etc. Developers will put in extra effort for someone they know personally, trust me.

    Monday, October 27, 2003

    Software Architecting: Planning your Solution 

    Approximately 70% of costs towards IT, is directed towards maintaining existing stuff. Only 30% goes into development of new functionality.

    If you're in the business to be profitable, this statement should ring a bell for you! Cut expenditure (simple math: it reduces profit!!!) by lowering maintenace costs. For most people, this is common knowledge. Maintenance adds onto your solution's TCO. You want as little as possible of this, and if possible, none of it at all. (Which is hardly ever possible)

    PLANNING. This is the most vital part of any project. PLANNING is the single development phase which reduces your solution's TCO the most. I see it all the time: a solution has a spiffy-looking GUI, and acceptable performance, which, in most cases, is enough to sell it. After some time in pilot and even in production, changes will be necessary. Enhancements will be necessary. This adds to TCO.

    I'm ranting about this today, because I see this everyday in projects I join or am part of. I'd much rather postpone a deadline a bit, and PLAN my project well. This will enable your solution by exposing logical API's, seperating layers to scale properly, and provide the user with enough dynamic options to adapt to changing environments you have anticipated. Of course, the whole 'planning' business is broken into many steps and phases, involving use cases and the few gazillion other concepts; there are many models to go by, like Microsoft's MSF model, to name one.
    I just wish that software producers would take this process more seriously before coding away just to get it on the table first.

    Sunday, October 26, 2003

    It's been a slow weekend regarding any 'tech'-activities, but I did complete my first 3 lessons in aviation yesterday :)
    Saw a cute movie today - it's a pitty the afternoon ended so soon, though! :D

    Talking about low-cost data-access...
    MSDE offers great functionality. However, it totally staggers with 5 or more users. (As promised!) Connection-pooling 5 shared connections does a good job for more than 5 users, but is only effective when your users don't request too much. MySQL is simply not an option in my book. Data-corruption is a common 'feature', among others...

    This page is powered by Blogger. Isn't yours?