Atomic Spin :: Elements of Software

While working on a mock library for C (CMock), I began to think a tool should be made that would take as input a written test with all its mock calls and automatically generate actual code that would pass the test. I thought it seemed useless to basically rewrite in source what you just wrote in the test. I used to think that. But then I remembered something that made me see the value in this seeming duplicative work.

While working in C for an embedded for PIC microprocessor system and at the same time working on a Java & Laszlo project using decent mock libraries, I found myself wishing for auto-mocking for C. We were already writing our embedded code following a Model-View-Presenter design pattern (read more here) for Test Driven Development. If we were to add a mocking mechanism, we needed something small and simple that would fit into a system with 256 bytes of RAM and 32K of ROM. Using Ruby, combined with the Rake build scripts we were already using, we implemented an initial version of a C mock library during a couple slow days at a conference. Using Ruby and rake external to the target system, we generated C code and headers with functionality equivalent to that available in object oriented languages with reflection. The generated C code adds little to no overhead to the actual production system.

Chad Fowler gave a talk at the last XP West Michigan meeting on November 28th. Chad shared his insights about career advancement and his mindset toward personal development, learning, and growth. He prompted us to think of ourselves, or our career, as a product. By treating our career as a product, we can start to put ourselves through a simple, iterative product development life cycle.

Everyone has heard of Offshoring. Clothing, automotive, and other mature industries have found that low wage centers overseas make good financial sense for certain types of work. In manufactured goods (particularly in mature industries), technological developments have allowed low skill, low wage workers to supplant highly skilled, highly paid workers in many tasks. Software is a bit different than manufactured goods in that it still requires skilled workers, but the draw of low wage centers certainly applies. And, technological development has simplified some aspects of programming and made common all types of computing technology. Cutting through all the hyperbole, Offshoring in IT/software is simply an indication that software is a maturing industry in a global economy. No longer are all software development projects cutting edge and comprised of the latest technologies. In a maturing industry, there are many needs that can, in effect, be met through commoditized services competing on price.

In comparison to Offshoring, Inshoring is not generally a readily known and used word. And where it is used it’s typically only as the yin to Offshoring’s yang, i.e. Inshoring is selecting a domestic vendor instead of a low cost overseas alternative.

The common understandings of Offshoring and Inshoring simply miss the full reality of what’s going on in the market. Domestic software companies are not recognizing the need to change the way they do software and do business. To survive and thrive, domestic software companies must truly understand the business model of Inshoring and embrace it.

In OO programming, instantiating, delivering and utilizing object instances is pretty serious work. If you don’t think carefully about where and when to use “new”, your entire system can suffer – code reuse and refactoring become more and more difficult, and you may not even know why it’s happening. Calling “new” in the wrong place is not uncommon… but it can be disastrous.