Thursday, 27 November 2008

Project evaluation a la carte

    I work as support administrator in huge outsourcing company. Team is big and dynamically growing and pretended to be big and happy family.
    I'm not very ambitions in career, indeed some of my mates are already occupy very prestigious management positions. Normally, I'm trying to avoid responsibility I can't control. I believe that most of people in top management NEVER control things, they are responsible for. But believe that I can do better then they is really phenomenal.
    Story begins in that nasty autumn day when manager said that we supposed to keep all tasks estimated planned for release in order to improve our proximity.
    Looks pretty simple for project you might have been working on, but I would like to bring your attention to terms marked in italics.
    Keep estimated doesn't mean to estimate just once: it means everyday estimations should be file.
    Release means not just single iteration, but all bunch of tasks from all iterations we planned or even didn't yet planned.
    Proximity? I actually didn't catch what the hell is that ...

    My answer was very rational, but disappointed manager quite hard: he told that I should elaborate way to define alternative approaches and insisted to have meeting dedicated to my response where I should have explained situation to the team leads. Actually my first response provided certain kind of workarounds for this: we can make releases shorter or we can make full estimation just once and then concentrate on support tasks. Otherwise we spend more than 20 hours a day just for estimations.
    I have conducted the meeting, but and made the same conclusions about situation, all other team didn't have so many issues, they were incoherent and releases where much oftener, but they supported my points and we closed the meeting.

    I was very surprised when suddenly I saw meeting invitation regarding proximity in my calender scheduled to 6 PM. Oh, God, did you forget how much time I spent on this?

    The meeting was eye-opener for me about how projects within our corporations are evaluated by customer. You know once per quarter we have so called evaluation questionnaires, where customer put marks from 1 to 5 to 8 different nominations. Proximity is one of those nominations and we get awful mark (2) for it. 2 means less then expected, so our proximity was expected to be better then it is.

    Team was very curious about this issue (in fact we had no other choice) and kindly asked departments head who also attended this meeting what is going on and how do we measure proximity?

    Well, we were explained that main goal of our meeting is to collect ideas how to improve it and our manager has already requested from customer explanation why proximity is was estimated so poor. Here is the letter:
Dear Donnie,
    Thank you a lot for filling evaluation form of our NTSR project!
    Could you please give us explanation what is proximity and what team is responsible for reducing proximity ...

    If you give us more extensive information we will put our efforts to find out why proximity is so poor and elaborate plans how to improve it.

Respectfully Yours,
    Julius Eiche,
    PM of NTSR project

    Ok, people, so what we can do with it? Donnie's reply was quite obscure, so it doesn't help us very much. Let us thing about this.
    Well proximity in Wikipedia gives us certain answer: proximity is ...
    Wait, wait, wait, wait! Do we really have no perception what the proximity is? Evaluation form is standard for all project in our organization! And it's not a first time it was introduced to the customer! Actually our customer put marks for proximity already several times ...

    Our manager was on top: he used so peculiar phrases to explain how important and difficult his job is. But, how about the result? We have no information about thing that has major influence on our project! We have nothing else that has such significant effect on the project destiny.

    Suddenly I realize that anyone can be not worse manager for our project than Julius: he has the same idea about evaluation as we all. Only difference is that he new about them and finding out how those measurements have been performed is primary task for any manager.
    Now I don't believe in managers and believe that if we got mark for any other nomination (tolerance, productivity, proactivity and so on) the reply would be the same: Dear Donnie, we are to stupid to understand what a hell that is. Teach us and hope that we will do better next 3 month.

    Meeting show me how deep problem was. In fact I'm quite anxious about 2 things:
- getting me to find out what are all those values in evaluation table
- requesting what else our managers have concealed that can be strike us so badly.

Tuesday, 18 November 2008

Corporate ethics. The guideline or the attribute?

Since I have moved from European company to American one, I never experience any cultural shift between two organization. In fact I didn't believe in so called "corporate culture". I'd rather believe in "corporate superstition" meaning by that usual way how people there used to get things done. Only thing that was changed for me was using rather American English than British. So now I write "color" instead of "colour" and try too update my written text and speech accordingly to American traditions.
In the aspect of team behavior nothing was going to be changed: Our team was planned as very agile and egalitarian: no managers, no subordination, no strict policies. We were pretending to the team of well-motivated professionals. And what I had seen there had indeed impressed me: team leaned to be unique within large organization. So I made my final choice voting rather to the team and people there than to organization as a whole.
Soon after my start I was told that our company is well-organized, modern and has some set of things that recognizes it as something special. I didn't pay much attention to this again: all things pretended to be informal, of course any company wants to recognize itself. "We are unique, we are the best". But they look like too isolated from each other.

And indeed it lasted like this about 3 month. Then things started to get changed gradually but steady: now we have at least 2 "pure managers" (who refuse to do any technical tasks) and 2 semi-managers (who supposed to do lesser technical tasks, but essential part of efforts are going to be spent on some sort of management).
I used to overtake some management tasks even at my first job, considering those tasks as inevitable expenses in order too keep whole team free from such routines. And eventually I can see that I'm pretty much successful in that: here I became one of those two semi-manager and unstoppable power pushes me to be even more distant from technical tasks.
Concentrating on management tasks, which include large amount of inbox and outbox items I began to suffer from lack of understanding the corporate principles.
Today the manner how I hold negotiations had been condemned by my boss. , but for me they were to trivial comparatively to things that was done in team by local managers. I was warned to not use informal lexis to not see and was informed about how it is had to be done within organization (oh, God, they spend so much time and efforts to create presentation for newcommers how to do such trivial things like sending mail). I agree with all pointhere, but anyway there are few points that make me furious about what's happening in our team
* They are breaking moral rules that seems reasonable for me: for instance, it's considered to be correct if higher manager sets responsibility upon lower even if it's not agreed with the latter.
* Those people are to idle to get things done. They will rather delegate to you creating reports even if they can do it more efficiently and faster
* They consider watching somebody meeting rules and sending important mail as attribute of their power.
In my professional life it was more critical to be honest with people and be direct rather to be polite. It doesn't mean to be not polite at all, but there was necessary to be so anxious about that.
Unfortunately my resources are exhausted to change the hierarchy of management that was raised here, I have missed already chance to keep team agile, and only thing to do is too keep Otto von Bismark principle:
Be polite. Even when you are declaring war.
That makes sense. So I believe in my talent of automation and self-learning: in a week or two I'll be polite, tactful, friendly and gentle ... at least in outbox :)

Tuesday, 4 November 2008

Thoughts about fixed-priced projects

Negotiating is domain area, which for most people is much more complicated to deal with, then even the most challenging technical task.
Once during one of our Agile club we have discussed fixed-priced contracts and applying agile methodologies to them.

This was quite hot topic: audience consisted of mainly agile adepts, but the projects they were involved indeed where fixed-prices.

In generally that discussion is not worth to retell it entirely, but there were some thoughts that may be very much valuable for me.

1. Above all, fixed-priced projects are normally more expensive and that means they are potentially more lucrative for executor (for IT company or team that works on them). It's a high price for professionalism. If I were millionaire I would rather have 100% service for 100% price:
I don't need analysts, testers, QA, IT department from my side to support YOUR development. I don't care if it's 400% more expensive: just give me entire calculation and risks and I will put your proposal under consideration.

So team has a good opportunity to provide product owner from their side and to make fair product for good price.

2. Commit or not commit that the question.
And all risks should be calculated before project is started

Here I have exposed one more thought: can we reuse that approaches that is used by venture capitalist when they do their business in IT
Unfortunately not: normally venture capitalists' approach is to be aware and to be acquainted with people: but they have money to take over risk, we don't :(

3. Fixed price project can be conducted as agile projects, but all necessary infrastructure should be provided by executor.

One of my colleagues proposed idea to specify if customer is opened or not. So if he ready for communication that better if he is not.

I also had thought about that: but I'd rather just exclude projects that depend on single non-responsive person as not good for me.
Just make me happy and don't ask any questions.

If your customer is large organization it's not a big problem if they are remote and not responsive. I've seen so many times when customer's representative not provided enough analyst or information about their product or requirements. But I have never seen customer that forbade their coworkers to speak with our coworkers.
Even in the worst case you anyway can talk with them, have discussions, drink bear or date their office managers.
You do have chance take information about how to make them happy (unless your customer is not Jesuits Order).
The costs of all this is a different thing. But since account management has word "presentation costs" normal business used to work with them, so IT business also have to.
So, viva forever! :)

Tuesday, 21 October 2008

Where to start building up solution?

    We have passed kickoff negotiations and concluded that we have keep on building new platform from sketch. Our team and customer is leaning to be agile as possible, so we immediately started from elaborating use case. Our initial plan is following:

  1. Login to the system
  2. User management tool
  3. other ...

    Is it a dream? Or deja vu? I have seen so many projects which started namely from those two items: login and user management, that I think there must be something enchanted and supernatural in those items.

Why login and user management is so important?

    Although login functionality is in 90% cases are the same (login, password, attempts to login before being locked and forget password, of course: nothing special) everybody wants to start from this. Probably because it's very evident part of the front page of any website.
    But pay your attention: this is nothing that can distinguish your web solution. In fact if you want to place on front page your logo and news and public speech of your CEO it would be further more recognizable and authentic. Don't you think so?
    Ah! I see: you still not sure what kind of info should you place on the front page. That makes difference: probably let's do easy start with login and password fields
    What then?
    Yes, sure we have very very sophisticated user management. Here how much roles we have, how to assign roles and groups to user, how to specify and handle rights of them on reading, writing and view profile of the assets?
    Wait a bit! Do we REALLY have assets in our system? Or any other entity? And do we really know what END-USER should see on our web page?
    In a second I realized an evidence: we DO NOT KNOW what our final user is going to see, but we already put efforts to build up user management tools ...
    I have a question: what kind of user do you have in your system? The answer would be (let us imagine a bit):

  1. Administrators
  2. Extended users
  3. Normal users

    And what is distribution of those users?

    Can you believe that? Our users are mostly common users and they are community we creating system for! Why do you so anxious about administrator UI, rights, obligations and privileges until you don't know what user should see?
    Well, administrator is a God in system and if we wrote Bible today we probably started from definition of God.
    This may be a reasonable way to found new religion, but enterprise system is not The Universe and not something we should worship (Sometimes it is really considered to be like this). Let's try to think another way: try to imagine what your usual user should see in your system. Do you have a few arguments why he actually should use the system? And finally if you have perception about

  • what user should be able to get from the system (features and information)
  • what user should be not able to get from the the system (security)
  • what is our benefit in the system?

    Does it mean that you can find out what is needed from user management, security, automation and so on just if you know aforementioned points?
    You probably will blame me, but my personal answer on the latter question is YES. Indeed, security rights, user management or any other management exist to allow user to have services they want to have, charge them for those services and to not allow them make harm to other users and system itself ...
    Even if your system is difficult for administrating but very friendly to end-user it can have success, but if it's not friendly to end-user whatever you have in back office it makes no difference for outworld anymore!

How should we start?

    Ok. Let's try to start with very small things ...

    I have a question: what kind of user do you have in your system? Answer is

  1. Normal users
  2. Extended users
  3. Administrators

    Oh! That's much better! Let us think about normal users first :)

Good luck!

Wednesday, 15 October 2008

Who should take care about negotiations?

Yesterday I was blamed by my boss because of using term "collective opinion" during meeting with customer. How strange, three years ago I blamed myself for thought that "collective opinion" actually exist. I consider this as something very rudimentary inherited from old Soviet times. And my chief actually shares this idea
In civilized society there is no entity like "collective opinion". It would rather be an opinion of your self-important ego

There was indeed more ado about this, but generally I can assume two basic reasons why "collective opinion" is to be blamed:
* Collective opinion means someone talks as representative of others, who apparently where excluded from the discussion
* Collective opinion means that nobody can take over responsibility for what is said.

My questions I would like to raise are:
* What is collective opinion in "civilized world" in general?
* What is collective opinion in Agile context?

I concluded that collective opinion as term should not be so bad surprise civilized world. It accepts terms like collective security and Agile community even sustains having so called collective ownership. Collective opinion not necessarily brings you to chaos of responsibility, like collective ownership does not. In XIX century Gustave Le Bon noticed that collective opinion exists and sometimes brings to very positive (sometimes to very negative :) ) results. The most great distinction was discovering that sometimes collective opinion is biasing from average opinion of people that are "collected". The next great thing Le Bon discovered is that rules how collective opinion (or in general collective mind) is built up can be investigated and used. Since his lifetime there are many different things emerged: Dale Carnegie practical psychology, people management in XX of Peter Drucker, new approaches in XXI century, public relations (both white and black) and so on: nowadays we have huge set of methods to bend collective opinion to some certain way and approaches to control collective mind. So even people suffer hearing about collective opinion, we should admit that it exists, it is used and will be used until humankind lives ...

What about agile? Can it mitigate parasite usage of collective opinion?

What 2 of 4 principles in Agile Manifesto declare emphasizing on Individuals and interactions, from one side, and Customer collaboration, from another. So Agile pretty straightforward about who should negotiate with customer:
as many and as much as team member can.
Agile suggests having egalitarian team with equal rights and possibilities to make a contribution.

That's very logical: in idealistic situation all team members can ask responsible person about this or that and use his (her) decision to go ahead ...
What about reality? Customer (Product Owner in SCRUM) is indeed very complicated role in Agile: I know few cases when we really had proactive product owner that was able to answer incoming questions team need to ask. But in most of cases product owner is not motivated enough or doesn't have enough administrative power/time/resources to make decision or team members are not skilled enough to ask "correct" questions (Correct is not that word, probably to be exact I should have used figure like questions, that bring us to correct decision in the shortest way).

In our situation when team members are not acquainted with product, distant from customer and have language barrier this trouble is even bitter. More negotiation skill of team members are very different: some people can hardly speak English ...

One friend of mine says that the key is to have proper people in team. That would resolve the problem.
But people can never be ideal!
Can we make team better than people we have?
Some people call this synergy (collective benefits prevails the sum individual benefits). Can it be applied here? How do you think?

Agile team egalitarian, but it doesn't necessary mean that all should have the same activity. One of us is better in DB administration, somebody in designing UI, somebody in investigations, why can't we consider negotiations as one more branch we can play with. What if you have in team guy who probably not so good in developing software but can do following things better than others:
* explaining how software should work to team
* explaining how it actually works and how it can be changed to customer
I would say that it's better to have such team member than to not have. And it's better to keep him more organizing negotiations than to try to smooth distribution of negotiations between different other people.

Some investigation I would like to do, will show how it works ...
(if it indeed works)

Tuesday, 14 October 2008

Programmers Competition

Recently I partook in organization duties in All-Ukrainian Software Programmer Competition called Programmania.

This event pretend to be ultimate for all kinds of developers in this country. Spectrum of tasks indeed very wide: from high low level languages to logical tasks, from very specific languages like 1C (development environment for accounting management in CIS countries) to generic questions about project management. We were lucky to have good sponsors and adequate anchors (thank you so much, Leviza :)) and that was impressive that competition was conducted in 3 different location. But by the same causes we had troubles:

There were too many "bugs" in tasks, as I was watcher during competition(not only preventing cheating was my duty, but also suggesting what we were intending to mean by very confusing statements in task bulletin. The bulletin itself was also very wide: there was no chance to finish up it all before time is over.

The most annoying for me was one candidate, that was pretended to be keen in project management and I was often asked by him to interpret what was written. Oh, no this time it was not failure of our authors and experts, that created bulletin, but there reason was quite complicated language that was used in PM tasks to knock out potential cheaters ...

How do we assess participants and their work?
Sum of all chapters (say all programming languages and tasks)
Average scores for all touched topics?
The most successful chapters?

In any case test doesn't reflect skills of participants in being team members. In fact, it was rather the fest of egoism ...

Although competition is used to attract potential candidates to our job offers, it's very naive to think that competition would estimate people in proper way ...

Wednesday, 14 May 2008

Motivation and demotivation

    Since one month I didn't touch my blog. This can probably misguide people who watch it planting feeling that I became more idle than I used to be. This is not true, indeed within last month besides my trip to Crimea peninsula on Black See (see the picture) I have understood many things regarding my psychology.
I'm in Crimea
    Oriental wisemen say that all wisdom starts with self-knowledge. The recent crucial question for me here is:

what is the major factor why I am staying for more than 3 years in one company against all odds of rapidly changing IT world?

    And accordingly to all customs, I am coming to the final conclusion when debates are getting closed …
    Before February 2008 my negotiations with all other people were based on following principles:

  • keep yourself busy and useful for team as possible as you can without loosing self-confidence

  • whenever you evidently asked for something by your team member consider this as opportunity to do something for team, i.e. small and urgent deals has higher priority than ongoing tasks

  • always be responsive, friendly and polite to all people. Consider idling and ignoring as something worse than being unfriendly or refuse

  • to people disliking you be as good and friendly as for others, just don’t tip them for that: conciliate this with people you like better

  • never look for reasons why do you dislike somebody or something

    Although I knew there were always few people that dislike me in ANY environment, but I can go long with this, as long as I have enough possibility to choose whom I speak to and negotiate with i.e. vary my closest environment. This position became very distinguishing for me especially in IT crowd: since most of people are introverts they won't pay much attention on you as long as you initiate it personally. And there are many ways how to avoid evident conflicts, since work is rather incoherent.
    But situation got changed quite dramatically when the boss of all it has been changed: the slight but very important difference between new and old one is following: the latter allowed me behaving like I’ve described above. Beside this there are very many other differences: they might be (and I’m sure they are) fatal for team, but not for me being in the team. I clearly understand that living in not at all prosperous country with underdeveloped economy I still can make my life happy. Why then I can’t be happy in unfriendly environment?
    Yes, I can indeed! The key is to give me responsibility I can hold and control on 100% and chance to develop it i.e. to make comfortable world for me and make it extendable (at least make me believe that it’s extendable). This is not obligatory large responsibility, but somewhere near should be potential for self-development.
    This motivates me still more than salary and career: it just makes me fun. The money is a fair price balancing between employers that tend to pay less and employees that tend to get more. I work primarily not for money, but for having time of my life.
    This is the most important motivating factor. But what is the most demotivating? Try to reveal them as direct opposition of motivating factors.
    Boss’ inconsistency demotivates me much: when he defines my responsibilities every day penetrating and changing them all time, he uses me at least ineffectively: instead of giving me right job forever he needs to control my job. Otherwise soon he won’t understand what I’m doing and what I have to do, which is even worse. Are you scared that job given at the first day not the most correct? Never mind, make sure that it’s useful at least even if it is not the most useful.
    Non responsiveness demotivates me much: IMHO, all people should be ready to accept feedback, it is not effectiveness, but it’s mathematical derivation of the effectiveness, so it’s a power to improve it.
    Professional ignorance demotivates me much. Man who doesn’t improve his skills regularly should not expect that his subordinated people will improve them. I know that project manager is quite challenging position: he ought
    1) to know how to work with software development;
    2) to know how to work with software developers;
In real life it is so complicated that no one can do both things, that normally your are stronger in one area and weaker in another. Ring-bouy for this situation is awareness of your skills: if you know how weak you are in one thing or another, or at least you are tending to understand this, you may find proper assistance in your team.

    Facing all this together my position is getting very unpleasant for me: people I would like to work with still exist but they are more distant than people I have to work with. It’s even more unpleasant than if I was surrounded with ignorant people with no aware of some alternatives are there. So from now I refused to meet my aforementioned principle #5 (never look for reasons why do you dislike somebody or something).

    Now I dislike people that make decision made by own “exclusive” experience. It is a root of all evil even if decision was right at some particular point. But I judge people not for their decision, but namely for the way how they had been done: In rapidly changed world you should not call your predecessor’s decisions ridiculous, because one day your today’s decisions might seem ridiculous to your successors.
    One day a good decision may be considered as bad or a bad decision may be considered as good ... But the way how decision was made stands still ...

Monday, 7 April 2008

Agile experience in complex projects

    Recently I've taken small break to rearrange my knowledge and experience gained in quite difficult projects that I have last 2 years. The mainstream of this period is continuous attempts to apply agile approachs in our team. Upon a time my endeavour ceases to look endless: We really indeed can be agile! (it's not obligatory so popular SCRUM).
    Recent XP camp in Kyiv (Thanks so much to Naresh Jain) and works of Gojko Adzic (I wish I knew that man earlier) made me strong believe that even our heavy project can be more "agilized".
    Presentation "Agile experience in complex projects" is an excerption of ideas I embrace about software development and particularly about project management. Of course, it was technically infeasible to look so broad topic through all aspects, but my purpose was to give an overview of subject, since I met so many IT people that never experienced problems like that, especially if they never participated big teams.

Q: How did God manage to create the world in 6 days?
A: Well ... there were no previous versions to maintain backward compatibility with.

    My presentation's focus is so called complex project. I've introduced this term myself, meaning following:

    Distributed enterprise application
    Distributed team in locations and cultures
    No solid corporate culture
    No men, who know entire system

    Few people among our community have already investigated problems and got the conclusions pretty close to mine.
    Although I've caught chill 2 days before, I hold presentation confident and quite successful. Questions of attendies discovered even more topics for future research.
    I heard question requesting patterns and antipatterns for agile-oriented project management. Although I like antipatterns very much (It was my first presentation at my host company) I didn't intend to discover "patterns" in this presentation. But the question is still very leading indeed: probably next post I'll devote to discovered antipatterns for project manager in my model. I do have a plan.

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