Tuesday, September 27, 2016

From Application Architect to Consultant Application Developer

To be frank, this is not a technical post. May be first post in this blog without any code snippet.

Let me start with a quote.

"A developer can be CTO, if he switch from Google/Facebook to a personal portfolio site building company"

People may disagree to this as CTO position needs more skills than a hardcore smart developer. This is from my experience with the industry. Technical positions depends on nature of work especially how critical the projects are. We can see people doing coding only in mission critical applications/frameworks who gets more money than a CTO of portfolio web site development company.

This post is regarding my job and role change from Application Architect to Consultant Application Developer. The above is not to get a self satisfaction by saying its common:)

What I was doing earlier

By title I was Application Architect. But due to the nature of company or nature of me, I was doing developer++ jobs along with some architectural jobs such as preparing the technical arch document, leading the technology and cultural(At least sone amount of TDD) changes.

Why I change

I understood that Application Architect is not developer++. That is a different role requiring different skill set and mind set though development skills are very important.

Does the arch do estimations? I was thinking no. But now I understood that archs needs to do estimations at least high level as in the beginning of the projects only architects know what and how exactly the technical things are going to be.

During my arch role I strongly believed as an arch I should never draw some boxes and run away. Instead I should make sure the project is delivered in quality at all the levels. The challenging part was code quality. I had spend too much time to ensure the project has good code quality and because of that I was not able to give attention to many other areas. I took that as a challenge to bring code quality to a culture which built around the core principle of "deliver on time even if its 0% quality". Later I understood, there is no meaning in giving something which is not needed by the stakeholders/sponsors. More than that if we want to bring code quality, it should be a mission critical project where failure in the application will halt the business. But the advantage of working in just-deliver projects is a kind of job safety.

When I do code reviews, I felt sometimes the team members are not comfortable especially when I ask why this is class level variable or public? They started murmuring that I am also like other high level managers who don't know or forget coding and not able to understand developer feelings.  I became tech lead at the experience of 3.5 Yrs and arch at 5.5 Yrs. I feel it was too quick and may be I missed the developer days and that is the reason why I am not able to understand their feelings. There is no chance to get the developer days back in the current company from the arch position because there are no mission critical or real critical frameworks.

Offshoring is a great way to reduce cost for developed countries and its good for countries which gets new jobs. I was in offshore for long getting more money than my friends working for business / companies. But its little tedious when comes to onsite and deals with offshore teams. We have to make sure offshore is happy without reducing productivity. It can only be achieved by frequent interactions. Due to the timing(East cost US and India), either I had to spend my night time or they have to spend their night time to get enough 1-2 hrs interaction per day. Some companies do understand that when they do offshoring for low cost, the quality will reduce and time will increase. But some won't. Then the trouble starts. If we want to get things done next day by offshore, offshoring doesn't looks great to both the sides though what ever relation is there among the team. 

Should the architects give more important to coding or meetings and other things? My understanding was arch should eliminate most of the meetings as they are technical persons and focus only on tech stuff. But its not true. Architects should be able to sell what he done and that can only be done by meetings and other inter personal skills.

Of course money was also involved. When a company bring people to US from outside, there is a  tendency to give the minimum required to process the visa regardless of their importance or role. There are a good chunk of people who thinks their destiny is to reach US and they will stay back in whatever salary is offered at first. At least until they get green card. But I am not in that category.

The good thing here in US is, there are so many resources available such as glassdoor.com which gives a good idea about market rates. Since black mailing my company with a resignation letter for more money was not my way, I decided to move out. May be in future, if there are convincing reasons will join back.

Everything needs a last fire to start. In my case there was a fire. From the beginning of my career at the company, I was busy with tasks one after another. The situation was like if I quit, company will impact. As a professional I never wanted to give such an impact. But recently one of the flagship product's AngularJS conversion project was taken out from me when the first phase is about to complete. This gave a good gap to say bye without impacting the company. Till this time I never received any call about any issue / query in the project. From that I believe I neved created any dependency on me and I did the proper documentation. Or the person who took over the project or my team is really great and they can manage themselves.  

What I do now/What I gained

Pure development for mission critical application(s). Every variable and line counts. No line will be checked in without lead's code review. If there is a build/MSI change I have to do it myself.

I am really getting the feeling from the developer side after a long time. How do they think on code reviews etc... 

If the app breaks the business will halt and it may lead to firing. No offshore calls or no need to be accountable for other person's work.Since I am consultant developer, my job is mainly to make sure my code works though I try to ensure the post coding activities are going smooth. 

I am not a critical part of the team as I am still learning the system. Hope I should be able to learn the entire system at high level with in 6 months.

There are many more learning such as how an architect should see the code quality. They should be first worried about the contracts/interfaces in the system. Let the team does the implementation. Architect should be able to design the system by contracts to split the tasks and give to team to get the rest. Some kind of piece work approach. To the extent, an architect should not ask what is the purpose of a variable if its internal to class or function. Let that be a worry for the leads who maintain that module and after getting production support calls at night they will automatically change.

Another thing is the socializing. I was in the impression that when I sent a mail with new idea everyone will read it as professionals. But it never happens unless they report to me and I have direct impact on their appraisal. As an architect I have to socialize the idea duing informal meetings and get support from all. At the end the credits to the idea may be on different person's account. But that is fine if we had sent one mail initially to the boss or publish an article in company blog:) 

What I loose

Arch position has knowledge of end to end system. What are the components and how they interact etc...Doesn't needs to go into details of application till a defect or critical situation comes. Another privilege is to take decisions and move on which gives the feeling of ownership.

Tuesday, September 20, 2016

IPC with SendMessage between WPF and WinForms apps

Communicating between processes is essential part of every big systems which we generally call as Inter Process Communication. If its large distributed systems the processes will be in different computers which we classify as servers and clients. Often we use http / http(s) based or other socket based communication mechanisms to do the job. In .Net world most of the people use WCF.

But in some cases there will be big systems running on same computer as separate processes and would like to communicate each other. We can use WCF here also with net.pipe binding. Since its same machine there are some more available options. Lets see what are those options. This post is about such an alternative which uses SendMessage API provided by Windows OS.

Clipboard

One of the dangerous forms of communication. Dangerous as user or any other application can copy new data to clipboard before our intended process reads data. But I have seen enterprise systems which uses this technique and working well for years.

EventLog

The sender can write to event log and the receiver subscribe to the event log entries to receive message. This will leave a trace of what has send back and forth between apps. But we should never use this for secure communication unless encrypted.

Standard In and Out of processes

One process can write to StdIn stream of another process and other can write to sender's StdId for two way communications. I have used this technique in one of my recent projects as it spawns processes frequently where publishing a unique WCF end endpoint was little difficult to achieve.

FileWatcher

Still many systems uses this technique. If there is a designated folder for messages and files are unique, it will work. in .Net works we can use FileSystemWatcher APIs to achieve the functionality.

SendMessage

Here we leverage the SendMessage windows API function to send a message to another process. That message then will be available to the message pump of receiving application. As we know the windows apps are running based on the messaging infrastructure. In simple words, the OS sends appropriate messages to apps about what is going on (eg:MouseClicked) with required contextual data and apps just process them. Its same for WPF as well though its hidden for normal apps. But there is a way to capture the message pump in WPF apps. 

A sample has been uploaded to github which shows how communication can be established between WinForms app and WPF app using SendMessage. Since the code is the true documentation, there is no more explanation required in this post.

https://github.com/joymon/Win32IPCDemo

Happy coding.

Tuesday, September 13, 2016

Interviewing developers for legacy application codebase

Many of us are working on legacy codebase and cursing the previous developers for what they did? Especially on code quality. It may be very difficult to understand others code, if there are no comments or documents on why they did something in a particular way. Then we have to assume what was going on their head when they were writing that piece of code. Based on that we have to take new decisions. If our assumptions are wrong, our decision will also get wrong and it produce more damage to the system.

So to work on legacy code, developers needs special skills to read previous developers mind by looking at code. Its something like investigating a criminal case or researching on fossils to find what and why it happened in the past.

What is legacy codebase?

My simplest definition to the legacy code is as follows.

Any code which contains technical debt is legacy code.
Technical debt makes code resist to changes. Now we have to understand what is technical debt in software engineering. Its nothing but the damage caused to software because of bad decisions. One will not take bad decisions intentionally. They might be forced to take bad decisions because of many reasons. When we say taking bad decisions, it may be taken by higher managers as well as developers. Don't think that developers are not involved in producing technical debt. Below are some reasons for tech debt.

  • Deadlines because of budget, competition & time
  • Lack of analysis, planning & design.
  • Lack of awareness.
In one way tech debt is good and that is what gives job to most of us :-)

Coming back to legacy systems. If we google, we get different views on legacy code. Below are some of the factors people are saying what makes a codebase legacy

  1. The system or the target platform for code is out of common use or runs in compatibility mode
  2. The codebase contains code for handling old and outdated things such as reading floppy disk or serial port etc...
  3. The code which works in production but difficult to maintain because
    1. The original developers are not around
    2. No comments or docs.
    3. No code quality such as no inheritance & overriding, no patterns, not following SOLID etc...
    4. So many short cuts.
    5. There are many dependent systems which restrict changes
    6. The third party library versions are no longer supported by vendors
    7. No unit tests to validate new changes.
  4. Any production code is legacy
If we look closely, all these reasons points to technical debt. Ideally we should pay off tech debt at some point. But nobody does because of budget and release timeline constraints hence the code becomes legacy.
But it didn't mean we can just keep the legacy code as is and go forward. There should be somebody to maintain the legacy systems as there were good investments went to build such systems.

Also we cannot guarantee that the new systems we build will never became legacy.  

Tips to interview for legacy codebase

As we seen in the beginning engineers who are going to maintain the legacy codebase needs special skills. Below are some techniques to be tried to assess them during the interview.

Inform them

The first and important thing is to inform them that they are going to work on a legacy codebase. That gives them a chance to rethink and reject the offer. There are not many developers with the skill to work on legacy codebase. As mentioned above it requires special skill sets than just writing code. If their body language changes on hearing the word legacy systems, we need to be cautious. There are still programmers who don't know what is legacy code and of course they cannot take any action based on this information.

I was part of interviews to hire for legacy codebase and I asked about ADO.Net knowing that the person is not at all going to write any ADO.Net code.  Most of the legacy systems will be having a working data layer and developers will be getting required object(s) when they make a call to DL.Also asked about new language features knowing that its not going to be upgraded in recent years.

Puzzle to find out the logic

If the candidate is willing to work on legacy code, the next step is to evaluate them whether they are fit for the job. One of the important skill required for legacy code maintainers is the ability to understand the intention of previous coder by looking at / debugging the code. There is no guarantee that there will be enough comments, docs or best practices. So the best way to evaluate them is to show a piece of poorly written legacy code and ask to find out what is going on.

If we have legacy code, we don't have to think about what to ask. We can get it from our codebase itself. one sample is below.
int a=0;
private void Timer_Tick(object sender, EventArgs e)
{
    if ((a++ & 0x10!= 0)
    {
        Foo();
        a = 1;
    }
    DoWork();
}
 
private void Foo()
{
    Console.WriteLine("Foo");
}
 
private void DoWork()
{
    Console.WriteLine("Do Work");
}

What is happening in this timer tick event handler? Most of the graduates who just came out of college can say the output of this code. But they may not understand the thought process of the developer who wrote this code. The history goes as follows.

Developer X wrote the original code. At that time there was only DoWork(). For every timer hit, say 1 second the function was getting executed. Later developer Y came and he had to do something every 16 seconds. By that time, this code became legacy. X is not there in company or too busy to help Y. So instead of introducing new timer and all, Y simply added a counting mechanism using variable a so that only in every 16th second the Foo() gets executed. Y might have added simple comparison of variable a to 16 and reset the same.

Later Z came to fix performance with  hardcore bits and bytes computer science background and he changed the simple comparison to bitwise operation.

If somebody thinks like this, he is perfect fit for legacy systems.

Puzzle to fix something with minimal changes

Another important ability required for legacy developers is to do things with minimal changes. Better they should fix the defects by removing code than adding more. We can easily find out these type of scenarios in the legacy systems. If the candidate is able to fix by removing code, hire him immediately.

Refactoring with tools

Refactoring is important when working with legacy systems. It doesn't mean one person should sit for months and refactor entire code base. Instead whenever we do a change do a small refactor. Instead of doing it by hand, it should be done with tools such as refactor menu in Visual Studio. Testing a candidate for refactoring skill requires machine test where we can observe what is his/her approach towards refactoring. They should be refactoring only after making sure its not invoked from outside via reflection. Also look whether the names they are giving are meaningful or not. If someone don't know how to name things and refactoring, its same as creating legacy code in the first place.    

Tuesday, September 6, 2016

Firing .Net events in separate thread

Suppose we are developing a library which has some events and we want our customers to handle the events in separate thread to make sure the UI is responsive. How can we do that?

Here is our class in the library which fires event every one second

class Clock
    {
        public event EventHandler<int> SecondChanged;
        DispatcherTimer timer;
        public Clock()
        {
            this.timer = new DispatcherTimer();
            this.timer.Interval = TimeSpan.FromSeconds(1);
            this.timer.Tick += Timer_Elapsed;
            this.timer.Start();
        }
 
        private void Timer_Elapsed(object sender, EventArgs e)
        {
            this.OnSecondChanged(DateTime.Now.Second);
        }
 
        protected virtual void OnSecondChanged(int second)
        {
            if(SecondChanged != null)
            {
                SecondChanged(this, second);
            }
        }
    }

Below is the code for handling the event normally. It handles the event in same thread and if it takes more time the UI will be unresponsive.
private void Clk_SecondChanged(object sender, int e)
{
    Log($"Event handler 1 - Second - {e}");
}

Lets see some approaches to handle event in separate thread.

Approach 1 - Guidelines to customers

Asking the customers to handle event handler in separate new thread or via ThreadPool is the simplest approach. But we don't get any guarantee that all are doing it right.
private void Clk_SecondChanged(object sender, int e)
{
    ThreadPool.QueueUserWorkItem((state) =>
    {
        Log($"Event handler 1 - Second - {e}");
    });
}

Approach 2 - Fire our event handlers in separate thread

Here we make sure each event handlers are executed in separate thread from the library itself. Below is the change required on firing method.
protected virtual void OnSecondChanged(int second)
{
    if (this.SecondChanged != null)
    {
        foreach (Delegate d in SecondChanged.GetInvocationList())
        {
            EventHandler<int> handler = d as EventHandler<int>;
            IAsyncResult ar = handler.BeginInvoke(this, second, nullnull);
            handler.EndInvoke(ar);
        }
    }
    
}
Happy coding...