Friday, 14 March 2008

Self-managed teams

    Recently, project manager in our team has been changed. My new boss is quite diligent in applying strict software development process. It's wanted and needed indeed: it's a really good thing when you know that some certain functionality will be delivered before certain date. At least management can sleep well in this case. But what chance of the dreams to become true in the team that steadily delivers many unexpected things, both good and bad. In complex projects work of developers are pretty much research work: everything brings piece of chaos to the complex system.     So all costs should be put under consideration not only in aspects of men-hours, but also in some very human-based and subjective opinion about increasing entropy. To be simple: each time you add new functionality you should think about chaos you make to your application. I will probably talk more about this effect later. So if we know that men-hours are not scalable (special thanks to Frederick P. Brooks), entropy increment is something even unmeasurable. In environment when nobody knows system, each development task means investigation, design, coding, testing, testing and testing ...
    Ideal developer for this is good motivated specialist that can "keep himself busy": he commits whole cycle from task specification to integration and he does not disdain to use any technologies due to solve any tasks. Although division of labour market still has people like that:

    I don't know exact reason for that. Probably IT are still very attractive not for just welfare, but also for self development.
    Such developer can be not so keen in each of his things he does, but he is much better for developing some kind of software than team from several people engaged in separated things:

  • he consumes less management resource than team of specialists of many sorts. It is really cool - the management resource is is inclement deficit.

  • he tends to self development and quickly embraces knowledge of applied system

  • he and people like that provides good base to create self-managed teams

    If you have more than 40% percent of people like that in your team, team becomes more or less self-managed: they able to distribute tasks themself, coach people who are not skilled enough. Broad specialists can also maintain whole development cycle protecting software from ambitions of others.
    There are also some disadvantages:

  • There are might be lack of people that likes formal management (with burndown charts, timelogin, issue tracking, road mapping and so on)

  • They like too engage themselfs with tasks they want. Remember that common developer designs only that things that he can and wants to create

  • They start fighting windmills when face challenging problems

    This means that team still need force that leads the development. This not always can be done by customer or head of developer. Customer and head masters can be so distant from development team that team doesn't feel leadership from that side. As it was recently discovered manage IT people is similar to herding cats (Last year I'd got this amazing book).
    Usually good developer asks somebody if he needs extra information about what to do and also he asks if he needs to make decision how to do. Many developers that are still with strong technical background doesn't like others to asks. So on one hand we need two roles:

    1. Somebody who knows what to do and prevent to do things developers supposed to not do.

    2. Somebody who knows how to do and prevent to do things in incorrect way.

    So on the following scheme I establish two more roles - architect and analyst:

    Analyst is pretty close to the meaning of analyst in all other models of development cycle. But destinctive features of architect that he is not just IT specialist that creates architecture or (even worse) designs software, but man who can reply on question how to make software. This not obligotary means that he should no everything, in fact this would be insecure for enterprise, and doesn't mean that he should create development document accordingly to standards himself, but he gains role of the knowledge base moderator. His artifacts is every document that helps to define how development team suppose to resolve their tasks, including guidelines, solutions, designs of crucial units in system, description of used technologies, that are not necessarily created by him, but in the good environment carefully selected by him from sketches created by team, external sources and self experience.
    Architect doesn't response for design anymore: it should be responsibility of people that creates software (the team). But he should be very responsive on questions that helps team to make decision. And the most important thing is that architecture not more process that bound to specific time or stage in project: architecture as development document should be steadily updated as new experience is incomming to the people that make software. This is very distinctive, because this means that we are not able to say "Oh, men! Congratulation - you have successfully passed the architecture stage, let's come for planning!". Because there is no more stage of architecture, it's continuous activity.
    What impact has aforementioned approach on analyst?
    Quite similar to one that has on architect: in complex project we can expect surprises of inconsistency of requirements or infeasibility of them analyst at any time within period of development. So architect is one who not only creates documents, but also use them to explain others what things are expected from software. Like architecture, requirement analysis is not more determined stage, but more or less continuous process. Analyst comparatively with architect should have probably longer gap between his start and start of the development itself, but boundaries between pure requirement analysis and support requirements are anyway obfuscated ...

Sunday, 2 March 2008

Macros in Visual Studio

I was stumbled by some trouble in Visual Studio 2008 today:
arghhh! macros refused to run!
Even the simplest code in VB demonstrates that VS doesn't run the code (Even if you put break-point on the single line):

Sub HelloWorld()
DTE.ActiveDocument.Selection.Text = "HelloWorld!"
End Sub

Only thing I did recently was that I installed several Windows Updates on my machine. And the same happends to my Visual Studio 2005.
Only post in MS Support knowledge base was not up-to-date. At least I had different symptomatics with this. In an hour cursing policy of continuous updates I run Visual Studio 2008 installation and forced it to repair.

Indeed that helped for VS 2008, but not for VS 2005

Challenging Visual Studio

After three month of silence I returned to my blogspot with fresh ideas. The most essential reason for this is that I was preparing special courses for our internal team and was busy with this as well as with managing our development process.

Recently I've discovered .Net framework 3.5 and Visual Studion 2008 for me. Thank God and Microsoft that irrespective to dynamic UI changes in popular Microsoft products development environment is kept conservative: It will cut down at least efforts put on getting used with new IDE.

So, what we have here:

  • WPF (Windows presentation foundation) - something that can make development of UI in web and on the desktop faster and more flexible

  • WCF (Windows communtication foundation) which can be used for transmitting data from one location to another

  • New language features (LINQ, anonymous classes, expression trees and lambda-functions

  • many features for ASP.NET

  • Office and Sharepoint integration features

To some negative clues I can put following:
Reduction of Composite UI and Microsoft Enterprise Libraries. Sounds like vendor set 2nd priority for these technologies.

In next posts I'll put more attentions at the new technlogies, but right now my general conclusion after overviewing new development environment is following:
Microsoft tends to move accent to Web-development, but maintaining strong position in desktop application by providing easy passages to integrate .Net applications to the Office, Sharepoint and other business solutions