Updates from a continuous developer

 

I have ideas. Many of them actually, every day. Especially when going to sleep and just before waking up I have loads of them, so I write them down in my RTM. Every month or so I clean up this list of ideas and edit, delete, and merge them according my feelings. Some ideas make it through several of these inconsequent selections. Those ideas are the ones I’d like to develop further – inventing a business model for them to make it work. So I start writing up an executive summary of maximum 2 pages according Guy Kawasaki’s blog post and there you go; another idea that needs a business model, team, thinking, investment, etcetera.

At this point I somehow can’t seem to take things forward; shipping it. So far, I have read many management books, “VC recommendations”, and blogs about how to make your business model sustainable, to somehow “fit” into the market you want to conquer. However, all these books don’t do it for me – they all provide too much text (is a 220 page guide still helpful?) and rules of “what to do” (based on the past) and not “how to do it” (better = sustainable). I was missing a strong framework that forces me to make sense of all my loose thoughts, while focusing on the business model itself and the future, learning from past success formulas and proven strategies (we all learn from the past), but without holding on to them too much.

Since last week, I’ve been reading up on Business Model Generation by Alexander Osterwalder (72 page preview here). This book is awesome! I was introduced to Alex by my friend Anne McCrossan about a year ago in regards to Somesso, but I didn’t get the chance to read this book until last week. Alex is a Swiss entrepreneur who teaches systematic approaches to business model innovation. The book is innovative on its own as it’s co-created by 470 other experts (not just by anyone – participants had to pay to join the dialogue). How’s that for innovation?!

This book is really easy to digest and fits well into my “low information diet”, which I wrote about earlier. In short and overseeable sections it provides an overview of the learnings from proven strategies and concepts like “blue oceans” (W. Chan Kim and Renée Mauborgne), “the long tail” and “FREE” (Chris Anderson), multi-sided platforms and open business models. Also the business model canvas is introduced (see below), which is indeed very handy. Thanks Alex and the 470 others who helped publishing this great guide! “

Post is by Arjen, click here if you want to read the post from the original url.

Stakeholder engagement is an important process to be carried through any project. The involvement and engagement can add value and increase the life of the projects that goes live.

Prince2 [Project Management Framework] suggests a good framework for the process:

1. Identification : Know your target people. Who is going to be affected by this project?
2. Analysis of Profiles: This creates inclusive environment where stakeholders’ points of views, influence power, conflicts, interests and tradeoffs can be elicitated. We can divide this group into 4 in the most basic form:
a. Support or oppose the project
b. Gain or lose as a result of the project delivery
c. See the project as a threat or enhancement to their position
d. Become active supporters or blockers of the project/its progress.
3. Defining strategy: The communication stragety will be defined:
a. For each profile, the method, format and frequency of the communication
b. The message sender and receipent are decided
c. What information will be communicated ?
4. Planning strategy: With the correct communicator, the negotiations’ timing and method will be planned.
5. Engaging stakeholders  ( Negotiations and Partnership): Carry out the plan.
6.Checking effectiveness (Monitoring): What are the results?

Although there are nice tools, like SoapUI for testing webservices, the hard part I found was verifying the xml send over http. The parameters were sent in correct format, the xml schema verified, but the values are placed as they supposed to be? The list goes on…
Netmom, Network Monitor, available under Administrative Tools, with WireShark solves the problem instantly. Quite easy to use, and the benefit is priceless!

There are just four steps to set up the Netmom, and Wireshark is good at displaying the result.

Step1:Open Menu->Capture->Addresses->Add
Put IP Address in Name and Address, then OK e.g. destination = 192.168.241.10

Step2:Open Menu->Capture -> Filter
i) Highlight Address Pairs
ii) Address -> Add
iii) Select:
* MCJS-WKS004 172.23.63.154 on left hand side i.e. your own machine NOT the 127.0.0.1 one
* Choose the destination IP Address in right hand column
iv) If no traffic is captured – then choose ANY as destination

Step 3: Menu-> Capture -> Start and you can run your test now.

Step 4: Open the saved file with Wireshark.

On Thursday [21st January 2010], I have attended to a seminar called “Tomorrow’s World Tomorrow’s Women” [TWTW] organised by BCS. Dr Sue Black is the organiser and founder of BSC Women in 2001, which has more than 1500 members. It was a nice interactive seminar about what should be done, and a bit evaluation of what has been done.
The bullet list from the seminar I got are:
-Apraisal for women should include more positive critics [around %90] and less negative critics [%10]. Women will always be sitting on the negative side…
- Girls at the age 10 can be motivated by meeting women proffesionals in IT, having a day would help a lot.
- After a certain age, people can select second jobs, so maybe women could be encouraged to shift to IT eve if they have not got education for IT.
- Instead of importing IT people, UK should grow its own resources…
- At the development role, women are stuck. They may work on managerial skills more to have a position on board, and influence people…
- %7 of board members of IT Telecom companies in Europe are women…
- Women, earning around £80k, are not interested in new positions offering more… [family life, husband is earning already...]

Wishing for more women in IT will not help, and should be put into pratice obviously, any ideas?

TFS work item identifies a piece of work for the project. Project managers can use this facility to keep track of the work done by developers, and developers can benefit from clear, specific work, with having the flexibility integrated into their development environment. Real time status of the items helps the projects to asset the risks, and delivers the project on time.
The existing work items are:
• Scenario A description of the user’s need or request.
• Bug A defect or deviation between expected and observed behaviour in the product.
• Quality of Service Requirement An expected deliverable of the final product. The deliverable can be an outcome, a problem solved, a feature, and so on.
• Task A stand-alone action that must be accomplished by a person or group of people.
• Risk A probable event or condition that can have a potentially negative outcome on the project in the future.
Instead of creating from stretch, we are going to export a work item from TFS, modify it, and import it as a new work item. At the very last part, I’ll show how to remove the work item.

Part 1: Exporting Task Work Item

To modify any of work items, you may use Power tools, VS2008 Command Prompt, and run:
witexport /f " c:\temp\task.xml" /t "xtf109" /p JLD /n Task

which stands for

f: file location
t: TFS Server Name
p: TFS Team Project Name
n: Work Item Type you want to export.

First, you may want to change value of the name of the “WORKITEMTYPE.”

The xml file has three categories:
I. FIELDS
II. WORKFLOW
III. FORM

I. FIELDS:
Fields defines which fields you want to show for that work item and what kind of behaviour they are going to display. You can remove any field you do not want.
Each field may have:
- HELPTEXT:
- REQUIRED or EMPTY
- The field may ask for a VALIDUSER
- The field may let only ALLOWEDVALUES, where you may modify “LISTITEM” for the dropdown values, i.e. Severity, Issue, Triage, and Priority…
- And the field may let to select one of the values listed, but can stay as empty as well with SUGGESTEDVALUES.
- DEFAULT

There is only one exception. “State Change Date” has a default clock as WHENCHANGED property. All other fields reference this value as WHENNOTCHANGED, especially the state change fields.

II. WORKFLOW
Workflow defines how the states of the work items are controlled, and it is divided into two:
A. States
B. Transitions

A. States:
At States fields, the required and empty fields are identified for the states. By default, there are three flows:
1. Proposed
2. Active
3. Resolved
4. Closed
You can add new fields, change their mandatory properties.

B. Transition:
The transitions define the workflow between states. For each transition you can force the user to enter data, i.e. Assigned User, Reason for Deferring, etc.
By default, for task, there are 9 transitions allowed:
From “” to “Proposed”
from “Proposed” to “Active”
From “Active” to “Proposed”
From “Active” to “Resolved”
From “Active” to “Closed”
From “Resolved” to “Active”
From “Resolved” to “Closed”
From “Proposed” to “Closed”
From “Closed” to “Active”

III. FORM
The last part of xml has Form fields, which defines the layout of the form. The UI of the work item is defined here, and you can implement your own design, without any restriction. You can define all tabs, groups on a tab, type of the control [drop down or textbox], docking styles, alignments and of course their labels.

Part 2: Importing

witimport /f "c:\temp\ToDoForBackEndTeam.xml" /t "xtf109" /p "Test TFS Project"

which stands for:

f: file location
t: TFS Server Name
p: TFS Team Project Name
n: Work Item Type you want to export.

Be careful about that you can’t import the work item unless you have a brand new “WORKITEMTYPE”

Part 3: Removing work Item

The easiest part is removing the work item:

tfpt destroywitd /server:"xtf109" /project:"Test TFS Project" /workitemtype:"ToDoForEbru"

This was my second time in OpenSpaceCode, and probably feels more confident about giving feedback and getting negatives and positives from those two.
Lots of positive feedbacks can be found on my previous blog;  however improvement starts with constructive feedback, where about I will to write now.
A. Collecting Offers:
1. Fact: Before the conference, MVC was twittered around, so there was a high expectation on it.
Opinion: We should be taking the risk to trade off a session and creating our own session.
Or maybe, we should be asking for volunteers to have sessions. [Did anyone complain about MVC session other than it was a bit fast?]
Or experienced people from old sessions maybe…
2. Fact: On the day, a stock of post-its and pens were given to everyone.
Opinion: Everyone holding a post it in their hand may not be an encouragement for everyone, since people offered sessions were the ones without post-its [maybe a psychological effect]
3. Fact: The number of people was more, but the subjects offered were more popular/general subjects.
Opinion: Last time, the offered subjects were too narrow, following the examples @adean opening speech. I find his words really influential. However, general subjects [generally a few subject on one big one [MVC and spark,] helped people to continue the discussions, and to be in the discussion.
Can’t be thankful enough to the number [46], since lots of knowledge and experience were on board.

B. Selection process
1. Fact: We did not categorize the offers into “difficulty” level, whereas in the first one we did.
Opinion: I think this was because we did not have many alternatives. But this should help people be aware of their “two hours” limit…
2. Fact: We voted for the most popular ones [same as first one].
Opinion: Makes it easy for people to change their session if they don’t the one they have.
3. Fact: Hosts are volunteered; they did not have to be the person who offered.
Opinion: Sessions missing the person who offered the subject sometimes suffered from “why we had this session”, but helped people to nativagate to any related subject they want to go on.
4. Fact: We removed the post-its and stick them onto the doors.
Opinion: Removing post-its from the wall posting to the doors is an agile thinking way I believe, and I like the flexibility. However, we can have bigger post-its, so that we can write host names on them as well.
5. Fact: Some sessions were the same as the old one:
Opinion: We should be asking/telling that we had a similar session last time, telling about benefits
6. Fact: We did not question/eliminate the offered subjects
Opinion: The session I was in was IoC, and it was a wonderful discussion. However, now I feel like it is more proper for an altnet topic…Maybe, the name “OpenSpaceCode” needs some filter on the subjects?

C. Sessions:
1. Fact: Wireless connection setup took some time.
Opinion: This could have been on main first room, at least a small demo, since the guide was a bit confusing…Instead of saying “create a new wireless network”, it could say “add a wireless network connection from wireless network connection properties”, easy?
Since each time, this event is welcoming more and more people, being more direct can help, and assuming next it can be another place…
1. Fact: For some sessions, installation was the session.
Opinion: Yes, it is a way of learning, but preparing yourself for the tool, and not being able to touch it makes you disappointed. To increase usability, an installation package [or a tool like hornget] can be useful.
If these sessions were hold monthly, then the group could benefit from the previous sessions
2. Fact: There was no PowerPoint.
Opinion: Loved the “sharing” and involving part.
3. Fact: The rules applied and there is no expectation from the sessions.
Opinion: This is sad. There was an ultimate goal, having checked the source code into google.code.
I would rather keep the pace slow and give a chance to at least two people checking the code in.
[Still not sure, if everyone knows that they a have Google code account or how to use it, [and yes they are developers, they are clever people...]]
4. Fact: Finding out what to build is hard.
Opinion: We can have volunteers to write some projects, or to search proper/alternative projects from openspace, so that we can start with that example, and modify it through our goal.
We can have a session/day for looking at openspace projects and discuss which ones can be useful…
And refactoring can be another session who wants to enjoy.

I had one of my best weekends so far, a weekend with wonderful .net developers. On Saturday, there was Openspace Coding Day and on Sunday
Alt.Net UK Conference. Grateful for EMC Cohango for hosting and Thoughtworks for Sunday lunch.

---

As open space coding day is supposed to be an unconference, there was no keynote speaker, no PowerPoint, and people were expected to offer a subject that is in their interest zone, without being an expert on it. The fundamental rules are:
- Whoever shows up is the right group
- Whatever happens is the only thing that could have
- Whenever it starts is the right time
- When it’s over, it’s over.

My choices were for IoC with MVC 2.0 for morning session, and MVC 2.0 with Spark for the afternoon session.

For IoC session, Autofac was the main subject to be discussed in the session, and discussed the benefit of IoC and why should we use?
After two hours, we could not find the reason that every project should use an IoC tool, i.e. Autofac, WindsorCastle, or Spring, or Unity; however we end up with lots of learning:
– As you apply the fundamental philosophy behind the loosely coupled components, you may not need a tool to take care of it.
– IoC and Dependency Injection are not the same thing.
– Once you register your container [at the start up of project], you don’t have register again.
– There are nice open source projects, i.e. an ecommerce project suteki you can check if you want to look at.
– There is a nice open source tool for easy installation of an open source project, hornget that I will try asap [after lots of praise].

MVC 2.0 and Spark session benefited from Jeremy’s inputs, and we followed ScottGu’s MVC 2.0 article and then spark was the popular view engine.

---

On AltnetUK day, I had “Software as Art” which forces me write another blog on that. The main discussion was around what makes it different software engineering process from an engineering process and art… My concern is I can’t see the design part, since if we are going to create artisan table, not an assembly line produced table; who is going to pay it, or how should we market it? [Yes, it will cost much more...]
Then, “What if your company renamed Waterfall as Agile?” was a discussion about why we should be using it, and if we have enough pain in the development process without being agile, how can we improve the process [without telling you are doing agile]. Nice inputs were
– If you can’t change your company, change your company by Fowler
– Don’t tell you want to do agile, do agile and tell them it is waterfall [start being agile].
– By picking up the most important parts first and delivering those parts will improve the process with small frequent shipments.
– Creating documents, reports won’t help software to be better! [believe in hearth]
– Lean Thinking is a nice to book to start thinking in agile…

Can’t finish without adding the idea of @serialseb: to rename altnet as alternative group, since we are all developers and we should be able to switch between languages/platforms [which should give us more power in terms of awarenes what we have and we are missing...]

All in all, it was wonderful as:

1. Sharing knowledge is helpful
– Looking into new technologies/tools expands your understanding, especially you are in a company does not use the latest technologies, and you are learning/trying them on your own…
– Any book/article you have to read gets high priority on your waiting list [or gets into your zone at least].
2. Sharing experience is priceless
– “How did your project fail?” is not a question everyone would share in your company, but here it starts discussions with twenty people with lots of feedback that you can take back.
– The pitfalls on software projects on a broader view, gives you more question to ask for your own project.
– There are always gaps to improve, and this kind of activities let you see the gap! [Rest depends on you]
3. Hearing other people’s questions/worries on a subject makes it more interesting and you start to question in a deeper philosophical sense.
4. Have the chance to meet and discuss with the people that you follow their blogs, i.e. @JeremySkinner,@serialseb, @gojkoadzic and their inputs were incredibly useful for both days.

There is a myth that at some point people starts to say that “tell business management about this.”
“But this is purely technical!”

I am not good at talking people coming from nontechnical backgrounds, and I find it quite interesting. They have eyes wide open, no idea what you are talking about; the literature you use is coming from MARS, and to take their attention and talking about the problems is not the nice part. However, when you start to talk about solutions, generally, it is a resource issue and it is hard to convince your needs/problems are really important.

From business perspective, I am sure everyone is coming with important things. And they have [hopefully well-known] priorities. They will take action based on the importance and relevance of the items.
What I can’t understand [or do understand but find it illogical] is that some companies have no roadmaps for some years. I find it harder to talk in a technology driven business that technological investment is in the very last rows of the priority list. 

In IT department, everyone is slow, not because it is UK, but they have no standards [or everyone has one].  Even the more process you create, the more slow you do your job, the more appreciation you get. If you deliver a project just to update a row for two months with three people, yes I am frustrated.

The business believes that if they continue what they are doing, they will be ok. They can be more than ok, they can be create state of art projects, but fine stick with the one we have and accept that ”updating a row should take three people two months, and all a hundred documents are useful.”  UML documents are a subject for another blog, I do believe in documentation, but not modelling each call that creates a constraint for the creativity for the developer. Then don’t call him a developer but a code monkey. And if the strategy is outsourcing the overseas code monkeys, my questions are still valid that “technology driven business” [not software house] should have a core team in-house…

or not?

What are barriers behind the delegation. Let’s look at with closer eyes:
a. Jealous:
      The delegated person can do a wonderful job.  We can realise/feel how bad we were doing the same task. A competency and comparison is unevitable
b. Guilty – Increasing to overloading
      By delegating a task, we are increasing the overload of that person.
c. Fear – Being overtaken
      We can be overtaken if the person is doing quite well. He can underestimate ourselves and can get promotion.
d. No Time
     Sometime, we don’t want to delegate because we don’t have time for delegation. “Telling what to do” takes more time than “doing it.”
e. Security
     The task we are doing can involve some secure information. We may not want it to be shared across other people.
f.  Enough skill/training
    Candidates for the task we are trying to delegate may not have enough skills/trainings. We see ourselves in power to be the only one to be able to do that task.
g. Love the task
    If we like the task, we are less likely to delegate it. Either it is easy or it gives excitement to us, we want to do that task on our own.
h. Hate the task
   If we think the task is useless and have repetition, too complex/ too easy, we may not want to share the task we hate.
i. Don’t like the person
   If we don’t like the person the less likely we want to give the task and watch him being successful.
j. The less motivation from the person
   If the candidates have less motivation than you have, and you don’t see them as willingful as you are, you may not assign the task, but do it on your own.

Knowing the causes helps to find out the solutions…

Tomorrow we will have the informal review session for the first increment [if you call it increment]. I had different kinds of challenges in this project, all team players coming from different backgrounds.  And always there is lots of to learn, bitterness of failure can be medicine for weaknesses.
1. Project scope was never clear as usual.
Lots of rework and change lists to go over many times [for models and code]
2. Team was not aware of how we are going to implement it. [Maybe some of them yes, but communication was not enough]
Incremental methodology should have been understood by project manager. All the project analysis phase is being done in six months, with one developer assigned. This developer was supposed to attend all the meetings, and tried to understand what she is supposed to be doing in six months. Analysts thought their task is over and they can wait for testing; delivered just UI specs. Developer was told to deliver models, design diagrams, code it, and keep up to date.
A project for more than a year, was planned in two increments [Increments were not really increments.]

Some people were complaining that the design documentation was not reviewed by analysts…[Can they?] Is this the point where waterfall becomes efficient? Something like spiral, but even if spiral, isn’t it the “working software” triggers analysis phase, not documents…

3. A new methodology called PSDM [an alternative version of RUP] was around to use, but no one had expertise. [Lots of hard work to understand how it is working with consultants, but they were mastering the project, lack of communication]
4. Roles were not definite [still not], and conflict of interests were stressful.
[Who should be the technical lead
-if we had one developer, why we would have one?
-if we have more developers coming on board, what is the role definition of technical lead? what is the expectation from him as technical details/giving support as well? if not who is going to the support?]
5. Analysis Model was done by the developer, [even consultants could not notice], and when she needed Design Model, she override the documents/system types. [No one was using those material, so no one has noticed...]
What is the point of creating documents….
Want to deliver “working software” frequently…