Sunday, 20 September 2009

The Age of Idea

Dear visitor,

I didn't write to this blog since April, because I was quite busy in trips and different kind of conferences. But them most valuable thought(s) I heard yesterday. There were few world-wide recognized men on AgileEE, who as I believed were steering the world of Agile. We were talking about generating and evaluating new ideas. I was especially active at this topic following the principle

listen more, speak less, write even less

I have heard many valuable thought regarding this topic, but one thought which was exposed by Mr. X was outstanding. I suddenly realized how complements it all I knew before and understood that now I am possessing something really brand new, something that never was expressed before.

When do idea come?


J. B. Rainsberger after this conference told that ideas never come over night, or they really can after 20 years of a hard work. Another guru named Davis Hussman told that brilliant ideas difficult to recognize as long as you haven't started them. I would like to rephrase what he said:
How many musicians can take note sheet and say "This is gonna be a good melody" before playing it. And there are as few people as people who can take a look on specification and say "This is gonna be a good product!"


And the most interesting thing Mr. X told me after the conference personally:
Normally there is just one good idea comes to single person in a lifetime. Days when there were people who was capable to generate million ideas are gone. I saw you got excited about your new idea, so guess you should stick to it, dedicate some web-site, blog, seminar, try it for some project ...

Yes, people, know I have an idea. My time is comming!

Tuesday, 28 April 2009

Dedicated to Account Managers


Finally, the day came, when my career at HindiBrain is over. HindiBrain rather differs from anything before I have seen.

I remember my first question when I was employed here. The lady who came up with job offer called herself “account manager”. So I naturally asked “What does account manager?” How strange that I didn’t get strict answer until the very end of staying there.

So what is behind this peculiar position?


There is an explanatory document inside local wiki-look-like knowledge base (one of those funny documents which usually are NEVER read by anyone except who wrote them). I read that document twice, than another time … I concluded I’m lucky to find the most favorite position in our organization. Would you like to ask me why it’s the most favorite?

List of responsibilities is pretty obscure, but it generally covers business and relationship development but excludes delivery satisfaction scores from the partner as well as team satisfaction. So if I not mistaken everything that needed from site of AM is to check budget calculations and keep customer’s mood in fit. And only first is more or less measurable. The latter always can be appealed to delivery satisfaction scores, team satisfaction or “unfavorable environment”. It’s quite challenging to imagine situation when account manager will have to admit that customer dissatisfaction is only his fault and caused neither by deliver nor by bad team spirit.

Another advantage of this position is authority level: It’s equal to top management and can get any project related information.
Administrative power is substantial: development team has to submit the orders of AM irrespective to current state of the project and direct agreements with customer.
List of activities are narrowed by book-keeping and negotiations, activities like requirement analysis, development and acceptance testing is omitted.
And the final responsibility note (my favorite): The activities above do not necessary mean that AM is doing all of them, yet, it means that AM takes the ownership of these items and is primarily responsible for their successful completion. He/she may delegate the particular tasks to particular people within the delivery organization. So the precious thing is freedom to choose what you’d like to be responsible for …

How to become account manager?


You have to be good negotiator and avoid conflicts. Popular opinion among top manager is that this person should be capable to manager multiple projects (don’t forget to include this to CV), be able to speak with managers by using their slang (keep in mind all teams from UAT to CMMI). To some extend organization should trust that man, who is going to be account manager, which is gained by month of work on similar position within organization. This work is normally quite distant from team players and even if you are so lucky to become AM very quickly technical and team leading background is decaying and become weak by that time.
It was funny when AM was claiming to improve team’s performance on 20% just by introducing man responsible for configuration management. Indeed so funny when you’re in team, but customer usually gets better to see something is changed in development team during time of uncertainty.

Ultimate Yes-man.


Well why organization keeps position of secretaries with salary of top managers?
Directors are also people and do not like responsibility, so it’s better to have someone associated with account better than associate accounts with themselves. Customers are always complaining about something and there is necessary to have single contact to them
One of the top managers called this position “backdoor” for the customer. Customer should be sure that there is always another way to get things done. Getting things done in this case is normally to get something team can’t commit or deliver. This normally means to break existing agreements with team.
For instance, customer wants more features within the same time frame. Team always says: well, it’s possible, but we have already plan, so you have to provide us feature we can drop. On another hand, AM always says big solid “Yes” and try to handle something on team level. I don’t know the reason, but AM and management in this organization does believe that there are always methods to increase delivery output immediately. It’s very dubious especially if you keep in mind that there are two levels of management (project managers and team leads) who suppose to increase output on daily basis.

Can this job be done without jeopardizing team efforts?


Well, I know teams usually are not perfect, sometimes they really need some external help to improve their capacities. But this is challenging task for different people, so AM can do literally nothing. It’s better to assume that:

There is no way to immediately increase team performance in 10%

I know one organization about the same size as HindiBrain. They have just one account manager responsible for customer negotiations while we have dozen. Now in crisis their business is expanding, ours is shrinking. Just ask me why …
Their account manager has no power over teams at all. And he has no doubt that customer may have minor report about underlying projects, so he is doing only one way: reveal delivery scores and reconcile customer moods. So if customer comes up with statement “Your team is a bunch of the lazy piglets! You have to whip them properly!” is treated not as action item to perform Chrystal Nacht at team side, but as bad mood of customer. Assuming this by man with excellent negotiation skills can be very useful in organization ...

Monday, 30 March 2009

The gene of the irresponsibility

    One of quality engineers from my former team asked me a stunning question:
- How many hotfix iteration have you been doing on average before the major release?

    You know, there is a special context of that conversation about our project and team, which still continuing without me on board. It was hard to admit that we used to have no hotfix iterations at all. To be precise, assume that hotfix is iteration when no functionality created, but rather fixed, visually improved or removed in order to keep software consistent and to not expose unfinished parts. In reality hotfixes became so usual recently that I didn't pay much attention that I had never done it.
    After rushing weekend I can confess: People, indeed I didn't have ANY hotfix iteration. In fact, I can see no argument why any project or team should have such iterations.

Aren't you able to predict that some certain parts won't be completed before?
Many will appeal to the hectic they suffer in the project and justify lack of strategic thinking. Still irrespective to what model did you choose agile or waterfall there are people whose primary responsibility is to make forecasts. So absence of any prediction can not be tolerated. Regarding our project I still have two arguments:

1. There is a difference between biasing within one iteration and biasing over iterations: I can imagine why team committed to 23 tasks was managed to finish only 20. That's something that forms team performance (or in Agile terms - velocity).
But how can you (team, manager and product owner) do 3 iteration in line and then you need 2 more?
2. We are talking about projects within one team and one product owner. New product implements functionality of the old one. Product owners and developers are mostly left unchanged. Users left the same. Even requirements can be reused. Only things were changed are technologies (I guess that's positive upgrade) and process (...)

Spit and polish in Software

    To my former NTSR project something called spit and polish has been introduced. Spit and polish is an iteration task which includes resolution of minor troubles and fixes.
Examples would be like incorrect rendering in webforms or some minor problems like only USD is supported (in control that suppose to have EUR and JPY).
IMHO, this is our project's KNOW-HOW and arguably the most stupid practice I've seen in IT. Pragmatically I would say there are 2 negative things about spit and polish:
1) everything can be claimed as spit and polish.
2) no one cares about time spent on that.

    The latter requires certain explanations: In fact developers are do not putting much efforts to register hours for tasks pretended to be spit and polish. And what they definitely not do is to describe what exactly has been done within spit and polish (because - saving time on that is primary reason why do we have spit and polish).
    But even if developers would be enough motivated to register time spent on that there is anyway deeper trouble ... From management perspective this time can be treated as nothing but direct loss: you can neither predict nor decompose this time. And that means that you can't do anything about it at all.
    The root causes of this is going through human factor and dissolving somewhere in the deepest aspect of human psychology. Being forced to deliver faster, people tend to shrink their responsibilities. Manager who suggested to deliver the functionality first and then the quality does not care about quality at all. I remember remarkable interview with Bjarne Stroustrup where he was saying
In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first.

I guess there is no hope that at some point the gene of the irresponsibility will be extinct. God has special providence for its adherents ...

Friday, 27 March 2009

JIRA Studio tips

I used to work with Atlassian JIRA Studio, which is from technical perspective the most developed project management environment. It provides immensely rich capabilities for iteration planning and for tracking. I can agree that sometimes it's very compicated to use it, since some of features need skillful approach to use them properly. As you can see in Atlassian case studies customers sometimes very happy to have professional environment for their professionals.

Customer's CEO persuaded that JIRA Studio saved up to 20% of time. But I'm pretty sure that with compliant approach you can have even greater advantage. Especially if you are technical professional and not scared with exploiting it.
From management perspective the most informative thing is your dashboard. JIRA Studio is quite tolerant in providing information to everybody in team, but to collect it effectively is really important. And dashboard is either your favorite place already or... you should take care to make it your favorite place.

So, pay some attention to the switch on the left top. Managing dashboard allows you adding and customizing different portlets. Many of them are useful, but first thing you have to do is to remove surplus: keep here only information about 1-2 projects you really interested in.
After you have released space you may want to populate it with useful information: It's better to replace projects portlet with single project portlet:

My favorite portlets are
Created vs Resolved Issues - this very good overall statistic for any project. Just try to guess how deep is rabbit's hole.
Average Time in Status and Average Age - This allows you to define to keep in balance QA and development teams.
Bamboo Plan Summary - yes, sure I always can view Bamboo's dashboard, but how good is to have everything on one page.
Recent Changesets - good monitoring tool if developers lean to demonstrate their laziness.

The disadvantage is that all this things (that belong to unexplored functionality) is badly supported and extremely slow. So after your Studio project exceeds 3000 issues you have to wait very long before you'll get dashboard statistics. Fortunately, dashboard can be interrupted anytime and there are workarounds to get summary you need.
The key is to use {sql} and {sql-query} tags. This is not only very flexible mechanism to retrieve information from JIRA, but also unrelenting security violation (oops ...) This queries allows you to get any info directly from database. Even if it's restricted accordingly to security rights. For instance if you are restricted to view document named Server access policies. All you need is to create page and put this wiki markup:



{sql:dataSource=ConfluenceDB|output=wiki|table=false}
select bc.body from content c inner join bodycontent bc on c.contentid = bc.contentid
where c.title = 'Server access policies'
order by c.version desc limit 1
{sql}

Where ConfluenceDB is database name where all wiki pages are contained.

But how to get information about Db objects? Well, you have to grow in postgre and learn JIRA database objects. The best way is too post this wiki page for everybody's disposal

Let's use [DB Schema|http://confluence.atlassian.com/display/JIRA/Database+Schema] and [PostgreSQL|http://www.postgresql.org/docs/manuals/] to retrieve information from JIRA Studio.

h5. How to get all databases
{sql:dataSource=JiraDS}
select datname from pg_database where datistemplate <> 't'
{sql}

h5. How to get all tables? {run:autorun=false|hideRun=false}
{sql:dataSource=JiraDS|output=wiki}
SELECT tablename FROM pg_tables WHERE tablename NOT LIKE 'pg_%' and tablename not like 'sql_%'
order by tablename
{sql}
{run}

h5. How to get all table columns? {run:autorun=false|hideRun=false|replace=tableName:jiraissue}
{sql:dataSource=JiraDS|output=wiki}
SELECT attname , pg_type.typname, atttypmod FROM pg_attribute, pg_type WHERE
typrelid=attrelid AND typname = '$tableName' and attname not in ('tableoid', 'cmax', 'xmax', 'cmin', 'xmin', 'oid', 'ctid');
{sql}
{run}

h5. How to get all tables from Confluence? {run:autorun=false|hideRun=false}
{sql:dataSource=ConfluenceDS|output=wiki}
SELECT tablename FROM pg_tables WHERE tablename NOT LIKE 'pg_%' and tablename not like 'sql_%'
order by tablename
{sql}
{run}

h5. How to get all table columns from Confluence? {run:autorun=false|hideRun=false|replace=tableName:content}
{sql:dataSource=ConfluenceDS|output=wiki}
SELECT attname , pg_type.typname, atttypmod FROM pg_attribute, pg_type WHERE
typrelid=attrelid AND typname = '$tableName' and attname not in ('tableoid', 'cmax', 'xmax', 'cmin', 'xmin', 'oid', 'ctid');
{sql}
{run}


For instance if you wish to know how many tasks assigned to your people and what are those tasks let's use this wiki markup
Opened tasks:
{sql:dataSource=JiraDS|output=wiki}
SELECT pkey, issuestatus, summary, assignee, reporter FROM jiraissue where
assignee in ('john', 'viktor', 'ashoka', 'kolyan', 'boss', 'vlado', 'kim')
and issuestatus <= 3
{sql}

How many tasks assigned with references to people:
{sql:dataSource=JiraDS|output=wiki}
SELECT '[~' || assignee || ']' as Assignee, Count(*) FROM jiraissue
where assignee in ('john', 'viktor', 'ashoka', 'kolyan', 'boss', 'vlado', 'kim')
and issuestatus <= 3
group by assignee
{sql}

The latter part is undocumented functionality of JIRA, so it might be changed if JIRA Studio is updated.
JIRA Studio is quite avarice to give information about itself. To get all information you have to trigger some exception inside: This differs from version to version but in most cases errors are connected with issue navigation. Fresh errors can be retrieved from here

There are many more tricks to make JIRA Studio to a dream collaboration tool.

Grateful acknowledgments to Dmitra and Mykola R. who helped me very much in collecting information about JIRA Studio tips and tricks.

Monday, 9 March 2009

Internet dog

    I remember good old times when in the late 90s this image appears on my very first mailbox.

    It wasn't as cute as any other jokes, but I remember that my conscience was totally agree on that: yes, said I, no one knows and nobody really cares who I am.

    Later on this message from the past is turning to be very dubious. Nowadays I'm convinced on Internet anyone knows that you're dog. Moreover be sure, they know everything about you: how often you bark, how often are you beaten by your host, how many puppies you have. The reason?

  1. Internet still makes you feel safe and carefree (It's better to say careless) about your privacy

  2. ... but becomes extremely effective in searching


    What if someone cares to be aware who you are? I was amazed how much information people can learn about me just googling my name: my profiles in social networks, my articles, publications, connections, out-dated CVs ... I'm not sure that I can memorize all those things better ;)
    How about specialized services to get information about people? Recently I have discovered PIPL.
    Oh cool, here I can type e.g. name of my classmate and find extensive information that he was graduated his college, then was hired by Morgan Stanley, then in one year got fired with some peculiar circumstances ...
Let me try to type my ex-girlfriend name: she's got married in USA and in two years got divorced (I can see it in her CVs). How about my former chief? My German language teacher? My friends? My enemies?
Do I need to know all these things?

    In most cases information is scarce: most of people (fortunately to them) do not have adequate representation in Web. Wait a minute! What if I type my name?
    Woosh! Those people who created PIPL know their job well. And if you get embarrassed with result to the right side you can see proposal to defend your reputation.
    Cool, isn't it? Have you ever though you have public reputation?

    Reputation defender will be happy to track news, messages, comments, suggestions and rumors about you from your lyceum's alumni journal to Forbes and Wall Street Journal in order to defend your reputation.

    Embracing Agile ideas I never think that openness and transparency is bad thing. And now I didn't change my mind. All you need to know is that you're responsible for your representation from the very beginning of your career and you only who cares about your privacy. In XXI century no one can expect that information told to someone or written somewhere will be not exposed to publicity. Whatever it was living journal, facebook or your profile at gay-portal.
    That's shocking, but not as bad as it seems to be at first site. Although many people will suffer from this, in most cases they are just people who are succeed in trying to be better than they are. No mercy to them. In most cases no one need to slander your name and you will have more or less adequate self-portrait in public sources

Have a nice day!

Saturday, 7 March 2009

C# vs. Java. Slight differences

So, there is a one month passed since I became Java developer ...

Long before I've started to develop something essential on Java, this language invoked very contradicting thoughts in my mind.

In early 2005 when I have started my career in IT, I've started mainly with VB and C#, but there were dozen of languages I used as supplementary: Python, Perl, PHP, VBScript, JavaScript, batch, NAnt scripts and so on. Among them Java turned to be something prominent. Since it was and is lingua franca of IT industry I extensively used literature and articles written by Java developers and architects. Even if they were created to be used by exclusively Java teams. Thus besides Anders Hejlsberg and Andrew Troelsen not only people like Martin Fowler and Mike Cohn, but also Craig Larman and Bruce Eckel became my masterminds in IT branch. Later on when I grown up enough to make presentations how to do software and how not to do I was leaning to make code snippets either Java, still being quite distant from development in Java itself. But to be honest I was never felt uncomfortable talking to my colleagues in Java. Java and C# is in fact very close to each other, but there is one more peculiarity that makes couple Java-C# very similar to language couples: C# developers normally better understood Java then vice versa.

Now when I delved deeper into Java, I realize how many peculiarities in Java are actually different: Java has larger heritage from C++ then C#.

In practice you can try to evaluate this code in both languages:


String a = "Falafel";
String c = "fel";
String b = "Fala" + c;
System.out.println(a == b);


In C# you'll have to use System.Console.WriteLine instead of System.out.println
In Java you'll get false, while in C# you'll get true. Why? Simply because Java compares addresses of a and b, while .Net compares content. You should use equals (before 1.6) and StringUtils (since 1.6) in Java to compare strings correctly.

How about casting? Have you ever tried evaluate this expression

(int)(char)(byte)-1

Experienced Java developers will answer: (byte)-1 will cause overflow, so you might expect something like 65535 on the very end. C# gets obviously the same answer, but by default C# compiler refrains to compile such a mess. You'll be kindly asked to use unchecked option on your own risk:

unchecked
{
    int i = (int)(char)(byte)-1
}


Working with numbers is very messy in Java (I will keep using references whenever I worked with arithmetic operations
Hex number 0xfa1afe11 will output positive result in C#, but negative in Java. The reason is that hex number with leading 1 treat as negative.
Floats can also challenge you: Java expression

System.out.println(2 - 1.1);

outputs 0.8999999999999999
while in C#

Console.WriteLine(2 - 1.1);

gets 0.9

NB: I must admit, that in .Net trouble with floating point operations are not finally resolved (MathLab and Maple in any case do them better)

Java has special class BigDecimal to perform operations with additional precision or value, but you might be careful using them either. Don't you know what is the difference between two following expressions in Java

BigDecimal dec1 = new BigDecimal(.1);
BigDecimal dec2 = new BigDecimal(".1");

Can't you guess?
Oh, you might be surprised that first one will output huge ugly number

0.1000000000000000055511151231257827021181583404541015625

Gurus highly recommend to use constructor BigDecimal(String) and not convert primitives to BigDecimal directly

Expressions like i = i + k; and i += k; are not equivalent in Java, although many Java developers think they are.

In any case my way in Java has just begun and it will take couples month until I will be able to cause another overproduction crisis in IT ...

Friday, 20 February 2009

Motivated by challenge

    Today I was meeting a customer as the representative developer. Fact that I was invited against all odds flatters me much: it looks like representatives were carefully selected by our management. I would be probably not frank, if I say that there was either pure truth or barefaced lie. And for sure exposing here what exactly was wrong would be incorrect. But to my surprise all lies became innocent comparatively to one tremendous truth that I heard today.
    Customer representative asked our manager Ron how we keep our people motivated. And the Ron’s reply was like this: our people are usually inclined for challenges. It is like part of our national identity. Our people always want more and more “interesting” tasks.
    Was he wrong? I wish he was. I would like to see my colleagues more pragmatic. This contradicts some values, I used to follow. But I have never heard about IT business dismantled because of some evil will: it is always good intentions which put business on the way to destruction.
    But he was more right then wrong! In reality every single day I confirm common truth: there are lots of people who are motivated by challenge. You can easily recognize them by their ambitions and deeds: They always commit before estimations, they overtime, they suffer, they estimate, they do, but then ... they commit again.
    Dear Ron, I must admit, I’m not a person of that kind, although I still like challenges. Sometimes I can afford to resolve easy task by a difficult approach, just because I like it, but a difficult task will be never resolved by even more difficult approach: I’d better apply easy one for a difficult task. And I argue that challenge motivates people. IMHO, it’s responsibility that motivates them.
Q: But what if people have spoiled sense of responsibility? And what if they not motivated at all?
    I guess this book can be guideline for people who would like to learn more about motivation. Who wants to know will know.
Q: What about people who are not motivated to learn something about motivation? ;)

Monday, 26 January 2009

Advanced search for advanced users

    German language is very famous for giving one-word description for very peculiar things. Advanced search functionality which forces user to fill several controls with different ranges is not exclusion. It can be described by word benutzerunfreundlich (User unfriendly). This is very good word because its pronunciation is as unfriendly for English-speakers as substance it describes.
    About five month ago I’d met introducing this functionality with a great skepticism and finally yesterday advanced search functionality has been finally removed from one of our products called Lupris.
    Lupris is system to perform research in goods data base to mine data for another system called XUT. Main feature of Lupris is browsing large amount of data. It also allows inputting market notes to the goods. Data records about goods are quite inhomogeneous and can belong to one of 16 different types. Some of those attributes like “Price”, “Short Name” and eventually “Type” are ultimate for all. Others like quantity for one type and weight in kilos for another can be treat as the same fields and merged in reports.
    Advanced search pretended to be good addition to existing full text search: product owners decided to create powerful search for advanced users. And eventually this functionality appeared to be poorly tested, badly developed and unused.
    This is very usual how so called functionality for advanced users terminates. But why advanced search is so unpopular? I'd better explain more generally: why functionality for advanced users is so unpopular? During my last visit to customer, I discovered that actually advanced functionality in our system already unknown to end-users! I have several reasons for that:

  1. In complex systems even advanced users are often advanced in one direction, but very naïve in another. That’s why advanced users rarely have common definition how things like advanced search should look like.

  2. Advanced users are rare. Unless we are are talking about usual enterprise systems, not something very specific or software development tools. Otherwise they are simply outnumbered by common users, which will find advanced search functionality at least useless.

  3. Among 10 advanced users there should be one even more advanced who will blame functionality in any case.


    In fact we should not prove why functionality for advanced users won't be used, but vice versa:
Before introducing functionality we should prove that it will be used

    Statement that advanced functionality would be popular one day is implied from very dubious assumption that every common user wishes to be advanced. That's not true at all: even for people who uses computer on daily basis.
    From technical point of view there are even more reasons: E.g. advanced search is very difficult to test and for bug fixing. Practically if your advanced search form has 10 input fields there should be like 100 possible cases just to conduct surface test of happy path.
    I have good example how quite large and successful company had burned its fingers on that. Microsoft has hundred of millions users and millions of advanced users and probably could count on strong community of advanced users, but their bid was IMHO wrong when they created search companion in MS Windows XP
    They were even forced to introduce Windows Desktop Search as something more usable. And since then many people still believe that advanced search can be usable an masse. XUT and Lupris product owners still appreciate advanced search and promotes it in XUT and other products within our organization. Ironically, they all use Apple, Sun and prefer open source products having apparently strong anti-Microsoft sentiments, but still repeat the same way of thinking. It reminds one of the suggestion about Microsoft
Can’t Live With ’Em and Can’t Live Without ’Em

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

Friday, 16 November 2007

Much better than one

    I have noticed one tool that I use rather often.
    I have laptop used both at home and at the office. Both at work and at the office I have desktop computer. Whenever I run some automated process on one machine I intensively work with another. It increases efficiency: Instead of waiting until NAnt and MSBuild will do their job and let me go ahead, I able to read, write, send/receive e-mails, prepare presentation and even develop on other machine. That's can be really big advantage for you, if you're already disappointed to have strong beliefs in multitasking OS.
    Until I installed synergy, it was very annoying to transfer some small amount of data between my computers (for instance, URL or connection string from PC to laptop). Even if you have instance messenger on both or well organized set of shared folders. My hands where getting tired because I should work with two keyboards and two mice.
    So, let's start with small practical introduction: So you have you're laptop (in my case PC-BORYS) to the left side of your desktop PC (BORYSDESK) with network connection established between them. Synergy is installed on both PC and laptop.

    It's convenient to share PC's keyboard and mouse, so consider laptop PC-BORYS as client and BORYSDESK as server. Here is main screen of synergy:

    On client all you need is to specify server name (either network name or IP), see figure above. On server you should set adjacent screens configuration. In my case it's two screens connected side-by-side like on figure below:


    Press start to share keyboard, mouse and clipboard on two PC's!

    You can't expect synergy to transfer windows and support drag-and-drop operation between PC's, but there are anyway quite useful features ...

Advantages:

    - synergy can work with any amount of PC's (imagine if you have 2 laptops and one PC)
    - clipboard buffer is also shared. You can copy-paste from one PC to another
    - configuration is saved
    - synergy doesn't require administrator rights on PC and perfectly works under normal user
    - clipboard buffer can be transferred with any kind of data (pictures, doc files and so on)
    - tray icon with connection status is provided

Disadvantages:

    - when server is very busy, mouse and keyboard can freeze
    - It incorrectly works with different keyboard layouts and functional key (so it's good when you use one variance of latin alphabet)
    - It gets stuck if you place large amount of data in clipboard buffer

NB: It's open source, freeware project, which hasn't been changed since 2006. The latest version is 1.3.1