The right experience of any craftsman in the world is acquired over the years. They polish their skills, learn the best way (practices) to work, pick up the right tools to accomplish things faster and with right quality. This is a never ending process. This is the place where the competence takes over the professionalism.

Seeking help is often overrated. Some people believe that it’s the sign of the weak. But I would say seeking help form senior, mentor or even to a junior isn’t at all a sign of weak.

I have seen people who sits more than 12-14 hours a day, work in the weekend. I came across the situations where people unnecessarily wasting time with their ignorance and specifically because of the lack of attitude to seek help. Sometimes a problem can’t be solved by sheerly throwing hours at it. Just take the help sort out problem, learn better aspects of it. Next time, the problem and the solution is yours!

Some poor managers and companies gives too much credit for people who tends to work hard though they’re not really productive. There are situations where you need to spend extra hours at office. But the spending-for-impression isn’t good at all. Either you’ve to correct yourself or to escape from the wrong hands you’re in. This kind of wrong assessment could create wrong attitude in the people and end of the day, they will be simply frustrated.

Fortunately I worked with some extremely good folks in the initial days of career. They were so knowledgable on what they do. Once the project lead told me a fact, please don’t sit with a problem more than an hour, it may spoil your energy and at times it could others as well. Always speak out if you’re stuck with something. Seek out for opinions and help for the problems you’re facing.

This reminds me of a problem, which we faced couple of years back. The project ran in to a tough mathematical problem. The guys in the room were the experts and experienced but there was a clear gap in their mathematical knowledge. Most of them are facing a tough mathematical problem for the first time.

The meetings were getting. Once-a-tiger guys were started talking about the obvious as if others in the rooms are fools. On the other hand, the mathematical experts were explaining complex formulas as a solution for the problem. Eventually some people tend to escape to hide their ignorance.

I was frustrated and as a technical lead of the project I told the project manager that the junior most girl in our team is really good at math and it’s good if she can join us. I heard a BIG NO. “You’re sitting with the experts. If you’ve problem in understanding what they’re speaking about do your groundwork but this is impossible”. But I was adamant about it and finally managed to get this girl in to the discussion. She really helped us to translate the problem between domains. If I had went back to my old math book, it could have taken time to solve the problems.

Seeking help from others isn’t a sign of weak. This could be risk sometimes but it’s important to develop the emotional quality and increase the mental capacity to take more things.

It’s equally important to seek the help in the right way

- Don’t sit with a problem for a long time. This could affect several things and you might need help to sort out the problems.
- Ask the right questions to the people. People tends to be busy and when we seek their time, it’s important to have basic groundwork before getting in the discussion. Sometimes a mere Google search can solve your problem.
- Know about the technology and problems you’re working on. There could be several best practices, caveats on using some languages/technology/process. Continuously improve your knowledge to accomplish things faster and better.
- Don’t walk for multiple times to sort out the problems. Reduce this as much as possible, it shows your quality of the attitude and the way you approach the problem.
- Seek a review/suggestion for the solutions as well. The solution you found might work well but there are some expert people who can give better suggestions or find edge cases in your solution.
- Finally, find the right guy to talk your problem. Some people are really bad by pushing their ignorance and handicapped solutions just for the sake of giving and answer or being a responsible senior to provide a solution.

Closing this post with a most important advice I ever received. Once I asked how we distinguish my work from others, especially juniors. He replied “It’s your knowledge, attitude, alternatives distinguishes you from others”

static void Main(string[] args)
{
    string str = "0x0013D";
    int value = (int)new System.ComponentModel.Int32Converter().ConvertFromString(str);
    Console.WriteLine(value);

    value int.Parse(str, NumberStyles.HexNumber); // Exception
    str = str.Remove(0, 2); // REMOVED 0x
    value = int.Parse(str, NumberStyles.HexNumber); // OK
    Console.WriteLine(value);
}

Again I am going to talk about a story.

One of the products which I have been working was being integrated and tested. It was also released to the other peers for their integration. Also the specification owners were verifying whether everything is at right place as defined.

The team was overloaded with huge number of bugs in hand, a mix of critical and minor issues.

The best thing had happened was the customer was an amazing guy who loves to prioritise the task. The priority sheet which contain several things in including the features, bugs, some sort of requirement stuffs etc.

The sheet was revisited almost every day. Sometimes twice in a day depends on the realignments and change in plans for the entire products, integration testing issues, resource availability etc.

The issues which could potentially affect the other resource were given high priority, the regression issues came second and the prioritised bug list of the products came after these. Anyway these are well connected and used clearly well.

Before he comes for the meeting mostly I used to have the list of the burning issues in hand and since we had a decent number of resources, it’s implicit that we should take up more issues. So there could be always more than one Priority 1 issues. Again to avoid the questions about the quality of our development, it was equally important to fix the lower priority issues as well just for the sake of numbers.

I just sat down for two three days and nailed almost all the low priority bugs. We used to demonstrate all the bug fixes and features before merging to the mainline. Along with few high priority issues I had demonstrated lot of non critical issues which I had fixed just for the sake of reducing numbers.

He was totally unpleasant with the demo. The question immediately echoed in the walls of the testing lab “Who asked you to fix the junk issues?” I replied “These issues were there in the list for a while and thought of closing it. Though it won’t help the product much but I feel it’s easy to focus on few things in our hand and the numbers actually make me uncomfortable”. He was silent for a while, then smiled and asked me to finish the merge.

As soon as I sent the merge mails to the whole product development group, he immediately called up for a meeting at my desk.

“Sarath-san, any time if I give this product to some good testers, they could fill up the bug list with the kind of issues you have fixed. You might be thinking that these issues are over but the fact is that we can find N number of issues like these. We are not reporting or I am filtering this in these kind of issues from you to make your life simpler. If you see the list of issues in the bug tracking tool, the numbers can drive you uncomfortable even worse. That’s the solid reason I am bringing up a single list even we have the bug tracking tool. I just want you guys to focus on the important issues. The issue which we were fixed was high priority few days or weeks back and our priorities have changed and we focused on other important issues.

He continued, “I can understand that you’ve fixed these things just to close all the loopholes in the product and also to reduce the numbers”

He opened the priority sheet which was nothing but a plain excel sheet. “Yeah I made a mistake. I shouldn’t have put these lower priority bugs in the main sheet. Just think your software is bug free (free of the low priority issues)” on saying this, he made the fixed issues in to the closed state and moved all the low priority issues to another tab and asked me to foget about it.

I was relieved and he said “Just make sure that you’re working on the highest priority issues.” Your team might be working on N number of issues but that even should aligned to the priority list we’ve”

Once after this incident, I learned how clearly the priorities could help us to achieve what we want and to focus on the issues which is most important to the product.

After this incident, I always focused on the most critical things to deliver. There are people who violates the priorities and focused on the pet stuffs, there are people who never had given information to re-align the priorities and risks. Just hunted them down in a good way.

Making priorities and sticking on it is never micro-managing people. It’s about sharing the same vision and the most critical things we need to achieve to reach the right quality to ship the product.

The transparency about work is very important. What the going on with everyone helps to identify how one work relates to other and then to derive the critical paths. Identifying the critical path can help us to weigh the priorities and put them in the right order.

Often people ends up with too many high priority issues which could easily spoil the list. It’s important reflect the priorities in the questions we ask, the meetings we hold and the things people working on.

I’d like to take Scott Berkun’s Amazing article to help me with some conclusions.

The key take aways from these experiences are
- Priorities simply make things happen. The goals, requirements and must be grouped, aligned and prioritised well. Group the other activities whenever required.
- The priorities list must organised in to groups and prioritised well. You can make list of things like Features, Bugs, Requirements etc.
- Priorities are dynamic in agile environment. This has to focused and revisited everyday. The priorities could change because of the internal or external factors.
- Make sure that the whole team is shared and aligned to the priorities and most of the time the priorities are aligned and cascaded down from the senior management to meet certain business objectives.
- Learn to say “No”. Several people had problem saying NO to people because this can be misinterpreted or contextual.
- Saying no is not a straightforward activity, it must be the result of a quality thinking considering the various factors like business objectives, schedule, budget, technical skills, learning curve of the product or technologies etc.
- It’s equally important to have a comfortable atmosphere within the team. Then it’s quite easy to pitch the ideas and convince the people to align to the same direction.
- Be a prioritization machine.

It’s very easy to change. Navigate to Tools->Options->Source Control->Subversion User Tools

There you can see the list of most famous comparison tools in the list and the status of availability. This makes your life simpler.

If you want to configure something which isn’t there in the list, you have to configure by clicking on the browse (…) button next to the each of the options which popup a handy dialog with the predefined place holders.

The project was almost in a shape. But all we were eagerly waiting to integrate 3D clinical measurement functionality. After several months of work the feasibility was successful and we prototyped and tested with some sample data available.

The integration of this feature started 2 months before the pre-release and we were in a good to go shape. But the hardware and the real-time data can be notorious. The 3D models started showing some problems and incorrect measurements. The team was passionately fixing the issues.

The issues did not end up there. One of our team members found a critical work flow which actually made us to rethink about the fundamental algorithm which fuels up the entire feature and we are almost clueless how to solve this problem. More time was required to integrate the newly found work flow.

I never allowed anybody to negotiate the quality of the product being delivered from our hands. The transparency about the project execution of the project helped me to gain a smooth and comfortable relationship with the customer. But yet, I have decided to integrate the basic feature we have implemented though we won’t be able to cover the new workflows found.

In the business point of view this particular feature has took a major portion of our fund and time. It’s important to show up the value as we are closing to pre-release stage. At the same time the issues have been properly communicated to customer. What works, what’s broken, what are the things we are clueless about were explained in detail.

Customer simply put a simple statement “Sarath-san, don’t integrate this feature, focus on other issues”. But I was not really happy about it because first is the business perspsective of it and the second is the hard work of few folks for several months! I was optimistic that we can integrate the fundamental feature within 1-2 weeks! I knew I was compromising. But I could not ignore my team’s hard work.

Customer smiled and left. Next day he came with the product manager and called me up for a meeting. He asked me to explain about this particular problem and he said if possible, he wanted to help to solve the problem. I repeated with all details.

He thought for a while and replied me
“Sarath-san, I would suggest you to remove this feature for this pre-release. I appreciate your hard work for this project and I am so happy about how the project turned out so far”

I said “Yeah but I am optimistic about it. I hope we can integrate it by next week. But there are some items which we need more time to fix. But the fundamental things are good go!”

He smiled and replied “Sarath-san, relax. Just think everything else other than this is high quality. The broken features can invite the risks from inside or outside. Tomorrow testers can report the issues and eventually we have to turn it down. The same thing can happen from the marketing team. Additionally the workflow of the product will be even more complex and we’re going to bet on something which we are not 100% confident about it. So rethink about it”

To ease up my perplexed mind, he said “Some other products we are deploying in this product isn’t ready. We can bring up these folks and you can have your demo later and at that time we can show our real guts!”

I was convinced and we focused on the fundamental features and had a great time demonstrating the feature.

Often good enough is not really enough to go. Things could be worse in the bigger perspective! If we’re willing to alter your standards from situation to situation, we’re going to have a tough time ahead. Compromise always send us back to square one and raise questions about our own talent and the quality of work we produce!

The typical usage of a file dialog would be as follows

CFileDialog f (true);
if( IDOK == f.DoModal())
{
   CString str = f.GetFolderPath();
}

If you compile this code with Visual Studio 2008 and above the code will succeeds and give you the folder of the filename selected by the user. But if you compile the code with MFC version 8.0 (VS 2005) or the prior version the code you will eventually you will reach in exception.
On stepping in to the code, you can see the following code with the MFC 8.0 implementation.

CString strResult;

ASSERT(::IsWindow(m_hWnd));
ASSERT(m_ofn.Flags & OFN_EXPLORER);

if (GetParent()->SendMessage(CDM_GETFOLDERPATH, (WPARAM)MAX_PATH, (LPARAM)strResult.GetBuffer(MAX_PATH)) < 0)
	strResult.Empty();
else
	strResult.ReleaseBuffer();
return strResult;

The internal implementation uses the typical window messaging system. The return of the message points to the string buffer which will be copied to the CString object and will be returned.
Though GetFolderPath can’t be used in a typical scenario, it can be used when you’ve your own implementation of the CFileDialog. You can use them in the internal callbacks and own implementations of override-able function as long as the window is being displayed.
E.g. see an implementation in a class derived from CFileDialog. Here the window is active. The call CFileDialog::OnOK will destroy the window object in the end.

void MyFileDialog::OnOK()
{
	CString str = GetFolderPath();

	// Do something like some validation
	MessageBox( str );
	CFileDialog::OnOK();
}

Changes in Windows Vista

In Windows Vista and above there are there several new shell interfaces introduced with extended functionality. The new changes in the file dialog and the Windows shell are incorporated in the new IFileDialog implementation. These interfaces are nothing but lightweight COM object and not part of MFC library. To provide the backward compatibility while exploiting the new features in the platform, Microsoft has changed the MFC implementation of CFileDialog with the help of using IFileDialog interface.
The constructor of the new CFileDialog now takes a new (default) parameter in the end called bVistaStyle. Inside the constructor of CFileDialog, the m_bVistaStyle parameter is set with this input parameter and the whole implementation of CFileDialog is implemented with condition checks. If it’s Vista Style File dialog, IFileDialog interface will be used throughout the life of the object.

See the description from MSDN

Both the appearance and the functionality of the CFileDialog with Windows Vista differ from the earlier versions of Windows. The default CFileDialog automatically uses the new Windows Vista style without code changes if a program is compiled and run under Windows Vista. Use the bVistaStyle parameter in the constructor to manually override this automatic update.

Obviously the old Open and Save file dialog API based implementations are remained intact and wrapped around with m_bVistaStyle condition check. You can find the implementation in the dlgfile.cpp (located underVC\atlmfc\src\mfc ).

Visual Studio 2008 (MFC 9.0) library has incorporated the above mentioned changes and behave properly.

For instance you can clearly see the code for GetFolderPath with the latest version of MFC library here. You can clearly see it uses m_pIFileDialog member of the class being used to get the folder path. The previous implementation is wrapped in the else case.

CString CFileDialog::GetFolderPath() const
{
	CString strResult;
	if (m_bVistaStyle == TRUE)
	{
		IShellItem *psiResult;
		HRESULT hr = (static_cast(m_pIFileDialog))->GetFolder(&psiResult);
		if (SUCCEEDED(hr))
		{
			LPWSTR wcFolderPath = NULL;
			hr = psiResult->GetDisplayName(SIGDN_FILESYSPATH, &wcFolderPath);
			if (SUCCEEDED(hr))
			{
				strResult = wcFolderPath;
				CoTaskMemFree(wcFolderPath);
			}
			psiResult->Release();
		}
	}
	else
	{
		ASSERT(::IsWindow(m_hWnd));
		ASSERT(m_ofn.Flags & OFN_EXPLORER);

		if (GetParent()->SendMessage(CDM_GETFOLDERPATH, (WPARAM)MAX_PATH, (LPARAM)strResult.GetBuffer(MAX_PATH)) < 0)
			strResult.Empty();
		else
			strResult.ReleaseBuffer();
	}
	return strResult;
}

Conclusion

You can make use of this call if you’re using Visual Studio 2008 (MFC 9.0) and above, you’re passing bVistaStyle as true in the constructor and the platform is Windows Vista and above. Also If it’s not required to provide backward compatibility, you can make use of IFileDialog interface than using CFileDialog class.

Links

CFileDialog::GetFolderPath
IFileDialog interface

Most of the people are familiar withthe famous Debug Trace tool Debug View which is one of the best and popular tools from Sysinternals (Part of Microsoft Now)

Download and launch DebugView with administrator privilege (choose Run as Administrator )

Enable Capture->Capture Global Win32 from the menu bar.

You can alternatively do this from elevated command prompt or explorer using WinDbg.exe /g

A small configuration hack can help you to install Windows Phone 7 tools with Windows Server 2008.

Download Windows Phone 7 tools from MSDN website
Extract downloaded vm_web.exe (or vm_web2.exe) using some unzip tools or using self extraction option by

vm_web2.exe /x

Find and open baseline.dat file from extracted folder (It’s formatted as INI file. Use Notepad to open it)
Navigate to section gencomp7788
Change InstallOnLHS and InstallOnWin7Server to 0

Run the extracted setup using
setup.exe /web

We had some solid requirements and prototyping on some new features. I had demonstrated one of the prototypes integrated to the product which essentially play back the images aligned to the ECG cycle acquired from the cardiac patient. The feature helps the sonographer to export the data as AVI. I simply tested the feature and quickly setup the demo as we’ve already crossed the deadline. Things were working just fine. This I had already seen in the prototype earlier. Fine. I demonstrated the feature successfully and was happy about it. I requested him to to try the new feature to get more feedback from him. He happily took over the system.

He simply registered a patient, then acquired the images along with ECG. He went on reviewing the acquired images, then he exported the cycles as AVI to the patient. He quit the application and opened the patient browser if appears under the current patient. Yea it’s there. I dint feel anything bad when he registered one more patient and start the application again. (Application won’t quit, it will be residing in memory always. They simply hide the window and release the resources and keeps on waiting for commands from parent application). He did the very same procedure again. It was working I was happy again. The progress bar has been displayed again and finished the export. Then he took the patient browser once more. Surprisingly the data wasn’t there under the current patient.

As I knew the code base well, I figured out within seconds what made it to disappear the data. I told him “I’m sorry, the new patient event not handled well. The code isn’t resetting/replacing the patient ID with new one. I can fix this. It’s just one line modification” and I was about to go back to my desk to modify the source.

He stopped me and smiled and explained, “Sarath-san, are you realizing that this is a serious security issue?” I could not fully understand what he really meant with security issue.

I did not reply. He continued “For programmers, it’s a one line code modification which takes to fix this issue. But think from a customer perspective. If you went a hospital with some small chest pain and the next patient is coming with some serious cardiac problem and what if his data being exported to your ID, then the doctor gives you the wrong treatment?”

The example was perfect. I could not think of a major heart surgery because of a system/sonographer’s mistake. That was kind of eye opener. Even after all these years I still remember the story.

Most of the time, programmers are either instructed to do some part of the code without having understanding of the impact. To make and maintain better software, it is also important to understand what is the big picture. What is the real impact. Always remember the issues being found during the development time is easy to fix, once it’s delivered to the customer site, the cost will be N times more, depends on the number of customers we’ve and the cost of deploying the patches. It starts from requirement capturing to implementation. It’s responsibility of the person who captures the requirements to test/inform the major uses cases, aspect and impact of the features. On the other hand, when we’re implementing something, it’s solely our responsibility to properly understand the requirement, big picture of this requirements and the impact area. It’s equally important to do regression testing to make sure that the existing functionalities aren’t broken.

When less competent people leads these activity there’s a high chance to have the information in pockets and do not explain the requirements properly to make sure that they’ve better control over the project (trust me, there are people). But that is actually making the product and themselves worse. Also it’s developers responsibility to bug the people enough to get maximum information and clarify the requirements.

We can do the hand written loop to remove the elements from the container. For e.g. if you want to remove an element vector you can do something as below. (note erasing element from a C++ container within a standard for or while loop with simple iterator++ will end up undefined result)

vector::iterator it = vec.begin();
while(it != vec.end())
     if( *it == 5 )
         it = vec.erase(it); // Remove and take the return of the erase function to safely reassign
     else
         ++it;

The above code is simple as it appears, it simply iterate through the elements and find if a match there for the value then remove it from the container. And it takes back the value returned form erase where it returns the iterator of the next element. If no more elements, it will vector::end

Now, the containers will have different implementations for the same function. A map::erase return void. So it’s difficult to give a single and easy strategy for each type of containers.

remove is a handy function defined in algorthm It’s easy to get confused to know what it does and distinguish between erase. remove remove (move) the elements from the given range. Mostly push it towards the end of the container. The function returns an iterator to the location where the moved elements located within the container. It essentially won’t remove the elements as such from the container. Here is the sample demo of using remove

// remove algorithm example
#include 
using namespace std;

int main ()
{
  int data[] = {10,20,30,30,20,10,10,20};      // 10 20 30 30 20 10 10 20

  // bounds of range:
  int* pbegin = data;                          // ^
  int* pend = data+sizeof(data)/sizeof(int);   // ^                       ^

  pend = remove (pbegin, pend, 20); // 10 30 30 10 10 ?  ?  ?
                                    // ^              ^

  return 0;
}

Now this handy function has an alternative version to give a comparator function which can accept the object of the type specified for the container. Inside the function, you can make decision to remove or not by specifying in the return value. In simple words, rather giving a comparison hard coded value, we’ll give a function to make decision for us. See the documentation and example here.

Erase-Remove tequenique is accomplished in following ways.
1. Move the elements to be removed to the end with the help of remove function
2. Take the return of remove and pass to the erase function as beginning and containers::end as end.
3. Finally the contianer will contains the elements which are not satisfying the comparator function/value.

#include  // the general-purpose vector container
#include  // remove and remove_if

bool is_odd(int i) { // unary predicate returning true if and only if the argument is odd
  return i % 2;
}
bool is_even(int i) { // unary predicate returning true if and only if the argument is even
  return !is_odd(i);
}

int main() {
  using namespace std;
  int elements[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
  // create a vector that holds the numbers from 0-9.
  vector v(elements, elements + 10); 

  // use the erase-remove idiom to remove all elements with the value 5
  v.erase(remove(v.begin(), v.end(), 5), v.end()); 

  // use the erase-remove idiom to remove all odd numbers
  v.erase( remove_if(v.begin(), v.end(), is_odd), v.end() );

  // use the erase-remove idiom to remove all even numbers
  v.erase( remove_if(v.begin(), v.end(), is_even), v.end() );
}

Reference:
Erase-remove idiom