{"id":34,"date":"2006-07-01T21:12:37","date_gmt":"2006-07-02T01:12:37","guid":{"rendered":"http:\/\/www.jrtwine.com\/blog\/?page_id=34"},"modified":"2024-05-06T18:09:57","modified_gmt":"2024-05-06T14:09:57","slug":"the-dangers-of-hidden-complexity","status":"publish","type":"page","link":"https:\/\/jrtwine.com\/blog\/the-dangers-of-hidden-complexity\/","title":{"rendered":"The Dangers of Hidden Complexity"},"content":{"rendered":"

One of the things that I think is very dangerous in today’s software development world in hidden complexity. \u00a0 Hidden complexity is best demonstrated by something that all MFC developers are familiar with – CString<\/code>. \u00a0 And I present a simple scenario to help with the demonstration.<\/p>\n

Imagine that you are interviewing someone for a senior developer position at your company. \u00a0 You have been handed a standard Q&A list from HR which includes some code-related questions that requires typed answers. \u00a0 \u00a0Question #3 seems simple enough: \u00a0 How would you format a random int value for display in a Win32 message box?<\/em><\/strong> \u00a0Each question has a 15 minute time limit for the answer, so after presenting this question to the developer, you decide to go and get some coffee.<\/p>\n

When you return 10 minutes later you are surprised to see that the developer is still coding his answer! \u00a0 They complete a couple of minutes later and present you with the following code:<\/p>\n

void \u00a0 \u00a0 \u00a0  Exam1( void )\r\n{ \u00a0 \u00a0  \r\n    long    lTheValue = rand();\r\n \u00a0 \u00a0int \u00a0 \u00a0 iCount = 0;\r\n\r\n \u00a0 \u00a0if( !( rand() % 3 ) ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \r\n \u00a0 \u00a0{ \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0   \u00a0 \u00a0     lTheValue = -lTheValue;\r\n  \u00a0 }\r\n  \u00a0 unsigned long \u00a0 lValue = 0; \u00a0 \u00a0 \u00a0 \u00a0  \r\n \u00a0  int \u00a0 \u00a0\u00a0 \u00a0 \u00a0 \u00a0 \u00a0iDigitVal = 0;\r\n\r\n  \u00a0 if( lTheValue < 0 ) \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\r\n\u00a0 \u00a0 {\r\n        ++iCount;\r\n        lValue = (unsigned long)(-(long)lTheValue);\r\n    }\r\n    else\r\n    {\r\n        lValue = lTheValue;\r\n    }\r\n    do\r\n    { \r\n        iDigitVal = ( lValue % 10 ); \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 lValue \/= 10; \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ++iCount; \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 } while( lValue > 0 );\r\n\r\n    char \u00a0 \u00a0*cpBuf = new TCHAR[ iCount + 1 ];\r\n \u00a0  char \u00a0 \u00a0*cpCursor = cpBuf;\r\n \u00a0 \u00a0char \u00a0 \u00a0*cpFirstDigit = NULL;\r\n\r\n \u00a0  if( lTheValue < 0 )\r\n  \u00a0 {\r\n \u00a0 \u00a0 \u00a0  *cpCursor++ = '-';\r\n \u00a0 \u00a0 \u00a0  lValue = (unsigned long)(-(long)lTheValue);\r\n \u00a0  }\r\n    else\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0\r\n \u00a0  {\r\n \u00a0 \u00a0    lValue = lTheValue;\r\n\u00a0 \u00a0 }\r\n\u00a0 \u00a0 cpFirstDigit = cpCursor;\r\n  \u00a0 do\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0 \u00a0 \u00a0iDigitVal = ( lValue % 10 ); \r\n        lValue \/= 10;\r\n  \u00a0     *cpCursor++ = char( iDigitVal + '0' );\r\n    } while( lValue > 0 );\r\n\r\n    *cpCursor-- = _T( '\\0' );\r\n    do\r\n    {\r\n        char cSwap = 0;\r\n\r\n        cSwap = *cpCursor;\r\n \u00a0 \u00a0 \u00a0 \u00a0*cpCursor-- = *cpFirstDigit;\r\n        *cpFirstDigit++ = cSwap;\r\n    } while( cpFirstDigit < cpCursor );\u00a0 \u00a0 \u00a0\r\n    \r\n    ::MessageBox( NULL, cpBuf, _T( \"The Value Is\" ),\r\n            MB_OK );\r\n    \r\n    delete [] cpBuf;\r\n \r\n \u00a0  return;\r\n}\r\n<\/pre>\n
So you take a good look at the code and see that it is performing a few distinct steps:<\/p>\n
    \n
  1. It is processing the integer value one time to determine how \u00a0much space will be required to store the int-converted-to-string value<\/li>\n
  2. It is dynamically allocating the memory required for the string value based on the calculation above<\/li>\n
  3. It processes the integer value a second time to actually generate the int-converted-to-string value and builds it in the allocated buffer<\/li>\n
  4. It shows the value in a Win32 MessageBox<\/li>\n
  5. It deallocates the memory it allocated earlier<\/li>\n<\/ol>\n
    Now, step back from the interview scenario and think about the code as it relates to the problem. \u00a0 True, it does exactly what it is supposed to do, but does it not seem a tad bit heavyweight for such a simple problem?<\/p>\n
    Most developers would look at that solution and figure that there must be a simpler way to do things, and they are 100% correct. \u00a0 However, the problem is this – suppose the developer, instead of writing the code above, wrote this instead:<\/p>\n
    void \u00a0 \u00a0 \u00a0 Exam1( void )\r\n{\r\n    CString sValue;\r\n    int \u00a0 \u00a0 iValue = rand();\r\n\r\n    sValue.Format( _T( \"%d\" ), \u00a0iValue );\r\n    ::MessageBox( NULL, sValue, _T( \"The Value Is\" ),\r\n            MB_OK );\r\n}<\/pre>\n
    Here is the problem with this code… \u00a0 Some inexperienced developers (even ones that do not realize that they are inexperienced) would think that this code is much simpler than the original code above, and might even consider it to be an acceptable answer. \u00a0 And, truth be told, it sure looks like a much simpler solution.<\/p>\n
    But would you believe that the code executed for this usage of CString::Format(...)<\/code> is actually more complex<\/strong> than the original code above? \u00a0 If the \u00a0CString<\/code> object was not a new object, and had already been used, it might be even more complex if reallocation was necessary. \u00a0 Now what do you think about this code? \u00a0 Not really as simple as it looks, is it?<\/p>\n
    Why would people accept the above CString<\/code> example as a better solution? \u00a0 Such is the danger with hidden complexity – there is lots of innocent looking code out there that looks “simple” to the inexperienced\/untrained eye. \u00a0 And there are lots of inexperienced\/untrained eyes out there.<\/p>\n
    As modern, professional developers, we have to start paying attention to the stuff going on behind the scenes. \u00a0 We have to realize that just because something looks simple, does not mean that it is. \u00a0 Knowing what your code is actually doing is important to understanding how to implement a solution.<\/p>\n
    When the hidden details involve dynamically allocated resources, things get really important. \u00a0 With today’s modern desktop CPUs offering things like true multi-core ability (Athlon X2, Pentium D, etc.), proper multi-threaded development becomes very important. \u00a0 However, most standard runtime heap implementations use a shared heap. \u00a0 When doing multi-threaded development, the word shared \u00a0normally implies contention.<\/p>\n
    If you do not know exactly what your code is doing behind the scenes, you cannot identify potential trouble spots where contention may be a concern. \u00a0 Oh, and BTW – since these CString<\/code> functions can allocate memory, it means that each time they are called is another possible exception point. \u00a0 Do you ever see developers wrapping each call to CString::Format(...)<\/code> with an try<\/code>\/catch<\/code> block?<\/p>\n
    This kind of ignorance is not something that should be encouraged nor tolerated in the field of software development. \u00a0 With the two top complaints about software generally being about speed\/performance and stability, developers cannot continue to be ignorant of what goes on behind the scenes. \u00a0 This is true for hand-written complied applications just as it is for managed\/interpreted ones built on a framework.<\/p>\n
    N.B: We are making some strides here – the new ATL-based CString<\/code> class seems to have a way to customize the allocators used. \u00a0 This is a very nice feature, but I bet it will be under-utilized. \u00a0 For example, Win32 developers have always been able to create pre-thread heaps to help avoid thread contention, but very few actually make use of them. \u00a0 The STL allocators can also be \u00a0customized in a similar way, but this is rarely done. \u00a0 As such, noone should expect these developers to suddenly wake-up and start using per-thread heaps just because CString<\/code> supports it. \u00a0 Developers have to rise to the task by gaining a more detailed\/deep understanding, and using that knowledge to build better solutions.<\/p>\n","protected":false},"excerpt":{"rendered":"
    One of the things that I think is very dangerous in today’s software development world in hidden complexity. \u00a0 Hidden complexity is best demonstrated by something that all MFC developers are familiar with – CString. \u00a0 And I present a simple scenario to help with the demonstration. Imagine that you are interviewing someone for a […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-34","page","type-page","status-publish","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t