Saturday, August 20, 2016

Small vs. Large

I recently transitioned from 1 contract assignment (with a large military/defense corporate behemoth, which I will call Company A) to another (a small commercial firm, Company B) and I decided to document the differences I encountered between them. They were both of similar durations (short term, 3 months, so I wasn't going to get rich doing either), and both were embedded development projects, but the differences were like night and day.

Company A used a slew of software tools:

  • Rally (a good web-based tool used to track project progress, assisting teams using the Agile Methodology)
  • Collaborator (a great tool by SmartBear, where multiple people could get together in a virtual forum and perform design reviews)
  • Coverity (a terrific static analysis tool)
  • Clearcase (a horrible software revision control system, now owned by IBM)
  • Clearquest (an even more horrible issue tracking system, also owned by IBM)
  • DOORS (a requirements tracking tool; geared to waterfall development, and is owned by IBM)
  • Rhapsody (a UML OO modeling tool/code generator; yes, also owned by IBM)
  • Python (scripting language used here to support unit and subsystem testing)
  • An internal web-based store (where users could install pre-approved/pre-selected software tools)
  • SAP (time-tracking, but their GUI implementation was clunky at best)

Company B didn't have the budget for the above set of tools (especially the IBM licensed enterprise tools). I couldn't blame them.

Company A was "Agile" in that they followed the process with the same fervor they displayed during the old waterfall development days. There were daily standup meetings, the sprints were roughly 2 weeks, the team committed to what they could do during the sprint, and everyone was supportive of the other. A bandaid. The project progressed, according to the statistics; milestones were being met, all looked good...  But the code smelled. Actually, it stank.

Company A was mired in bureaucracy. I was hired and given a report date. The last Friday before that report date, they called, asking for a 1 week postponement. My desk wasn't ready. When I do show up (1 week later), it still wasn't ready. My computer was finally set up about 1 week after that. It took another 2 before I had external internet access (apparently I need managerial approval to access sites  like C++ Reference, or python.org).  I needed admin privileges to change the name of a shortcut icon on my Window's desktop.  I couldn't install Wireshark (a tcp sniffer REQUIRED by the project mandated testing suite), without getting an approved smart chip on my photo-id badge. The facility did DoD classified work, so BYOD was not allowed.

Company A's IT support was very good. For all the problems they had to deal with, they all get high marks.

Company A's software architecture was riddled with obfuscation. Layer upon layer of abstraction; they had an Architectural layer (I kid you not), a device layer, an interface layer, and then they added multiple inheritance, so that everything incestuously mixed together. They had structural problems, in that every message was a separate class; but behavior was hard to trace. They had large enums in separate layers that seemed to duplicate each other, but their ordering was different; then they had code that tested layer 1's enum value, only to assign a layer 2 enum value.  Switch/case statements running for hundreds of lines.

Company A believed in Model Driven Development, a paradigm I have NEVER seen done well.  The Rhapsody model was split into separate entities; and code was generated from each. There were over 10 different specifications on how to compile the project (most of them didn't work, so why were they still in the model?).  The test framework was in Clearcase, but you checked it out from a separate repo (using svn), and whatever was in Clearcase was not to be trusted.  BTW, during the regression tests, the test framework when encountering an exit condition would play a sound snippet from Star Trek that was annoying as all heck.

Normally, in Clearcase you have separate streams (an Integration level stream, and the developers worked on clones called Dev-streams). Approved changes were promoted up to the Integration stream, and the other developers rebased their dev-streams to remain in sync (but, wait too long, and merging the changes get problematic). So, at the standup, we were told we could rebase our streams. I did so, only to find my stream wouldn't compile. Why? Someone checked in whole model components that had illegal code generation stubs (e.g.: boolean functions that had no return statements, or missing header files that were not to be found).

I don't care how Agile you profess to be, that rebase is equivalent to Original Sin, and grounds for banishment from the Garden. So, around this time, I was also approved to use Coverity.  I ran the report on the Integration stream, and the list of warning and errors took my breath away. When I volunteered to fix them, I was told that it could wait (for what?) until after the delivery (when our customer would get this load of deep ****).  I wished them good luck, but I was relieved to go.

Company B was also doing embedded software. Git was used for version control (something WAYYYYYYYY better than Clearcase), no UML models needed, and YOCTO was the cross-compilation/development environment. Drop the bureaucracy, because there was none. Have a problem? Fix it. It's as simply as that.

Now THAT is agile. It is what you do, not how closely you follow some process with a label.

Company B's IT wasn't comparable.  Certainly it wasn't as large as A's. But I had a work computer and desk in the Director's office waiting for me on day 1.

A month later, YOCTO had issues downloading files from GiHub using the command-line. No issues using a web browser.  Somebody was playing around with the firewall...  I sent a test email to my gmail account, and responded back. Gmail got the test email within a minute. The response took two hours to get back into MS Outlook.

Oh well, no place is perfect.