Adventures in Tech

One of my favorite times at work is when the interns in my organization present the projects they have been working on for the past 10 or so weeks. It is amazing to see what they have accomplished during that period, and its impact on the business.   In my groups, I always make sure that everything the interns work on makes it to production and has visible business impact. The interns enjoy that quantifiable sense of accomplishment and seeing that their work lives in a launched product and improves some aspect of it.   After the interns demo their projects, I schedule follow-up 1:1 meetings with each of them. During the meeting, we go over their experiences during the internship, what they have learned in the process, and how can we make the experience better the next time around.   Their suggestions are always on point, constructive, and actionable. The conversations invariably drift to learning more about Microsoft, and what advice would I give them to have ...

One of the areas often overlooked when writing software systems is thoroughly understanding what needs to be developed. Specifically who are the users that are going to interact with the system, what are they trying to accomplish with the software, and how is the system expected to behave under normal and error conditions. In short, developing software requirements and specifications before the software is written. " Software Requirements 3 " addresses these questions, with clear answers and advice in a rather longish format of roughly 673 pages. The book starts with a story about the importance of software requirements: a case of an employee who changed her last name without getting married, and the accounting software's inability to handle the change, with the repercussions that the employee will not get paid until the the "bug" is fixed. The book mentions that this is not an atypical situation, and that  ... errors introdu...

Not all of us are lucky to work with greenfield projects; the majority end up working with codebases that we inherit. These codebases have had their share of modifications that moved them away from the original elegant design: bug fixes, feature additions, and enhancements that were done in a hurry because of delivery pressure, without regard to code hygiene and future maintainability. The code then feels heavy, complex, hard to understand and more painful to maintain. There are a lot of ways to characterize code complexity, but the one that jumps to mind is "cyclomatic complexity" described by the McCabe paper from 1976  http://www.literateprogramming.com/mccabe.pdf .  The paper describes how to measure the cyclomatic complexity of different program control paths, and recommends a bound of 10 for manageable code complexity. NIST also selects the same number http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/chapter2.htm . The numbers, despite being arbitrary, provide...