Monthly Archives: January 2016

Last week I attended a presentation by Brendan Murphy from Microsoft Research – Cambridge. Dr. Murphy presented on his research regarding software development processes at Microsoft. This post contains a summary of the presentation and my thoughts on the material presented.

The discussion focused on the impact of particular architectural and processes decisions. For example, how does the choice of architecture effect the deployment of new source code. Consider a micro-service architecture in which several independent components are working in concert; it is likely that each of these components has a unique code base. Deployment of updates to one component must consider the effects on other components, i.e. a loss or change of a particular functionality may cause problems in other components. Perhaps using a more monolithic architecture reduces this concern however software monoliths are known to have their own problems.

The way that we, as software engineers and developers, manage variability in source code is through branching. Code repositories often consist of a number of related branches that stem from a “master” or main version of the code, branches often contain a specific feature or refactor effort that may eventually be merged back into the main branch. This concept is familiar for anyone who uses contemporary version control methods/tools such as Git.

In his presentation, Dr. Murphy discussed a number of different branching models, some of which have been experimented with at Microsoft at scale. Different approaches have pros and cons and will support different architectural and deployments in different ways. Of course, when considering the effect of different models it is important to be able to measure properties of the model. Murphy presented several properties: productivity (how many often in time files are changed), velocity (how quickly changes/features move through the entire process), quality (number defects detected and corrected in the process), and coupling of artifacts (which artifacts often change together). These can be used to evaluate and compare different branching models in practice.

The most interesting part of the presentation, from my point of view, was the discussion of the current work based on branching models and these properties. In theory, a control loop can be used to model an evolving code repository. At every point in time the properties are measured and then feed into a decision making unit which attempts to optimize the branching structure based on the aforementioned properties. The goal is to optimize the repository branching structure. Murphy indicated that they are currently testing the concept at Microsoft Research using repositories for various Microsoft products.

The main takeaways from the presentation were:

Deployment processes must be planned for as much, if not more, than the software itself.

Architecture will impact how you can manage software deployment.

Repository branching models have an effect on version management and deployment and need to be designed with care and evaluated based on reasonable metrics.

A control loop can theoretically be used to evolve a repository such that there is always an optimal branching model.

From my personal experience working as both a contractor and employee the point of planning for deployment is entirely correct. If software isn’t deployed or unaccessible to its users it is as if it doesn’t exist. Deployment must be considered at every step of development! The presentation did cause me to pause and consider the implications of architecture affecting the patterns of deployment and required maintenance. As we continue to move towards architectures that favour higher levels of abstraction, in my opinion, one of the primary concepts every software engineer should embrace, we will need to find ways to manage increasing variability between the abstracted components.

The notion of the control loop to manage a branching model is quite interesting. It seems that we could, in theory, use such a method to optimize repositories branching models, but in practice the effects of this might be problematic. If an optimum is able to be found quickly, early on in a project, then it seems that this is a good idea. However, if weeks and months go by and the branching model is still evolving this might cause problems wherein developers spend more time trying to adapt to a continually changing model, rather than leveraging the advantages of the supposed “optimum” model. However, a continually changing model may also force development teams to be more aware of their work which has benefits on its own. Really this idea needs to be tested at scale in multiple environments before we can say more, an interesting concept nonetheless.

For those of you who have never worked with web technologies allow me to say one thing: it’s the wild west out here. The novice web programmer must navigate a myriad of new hazards when coming from comfortable homes like C and Java. Just a few of the dangers include: teetering technology stacks, silent failures across multiple machines logging vital debugging information in obscure locations, and niche technology which will solve your problem today for a maintainability nightmare in the future.

Now, I may not be able to call myself a web dev novice anymore but as I begin to see the edges of the big picture I am amazed at the total lack of consistency in implementation and documentation. While working on my current project I’ve examined quite a few different technologies and paradigms but today’s issue comes back to one we thought we could trust, CSS.

CSS, or Cascading Style Sheets, is used primarily for setting the visual style of a markup language like HTML. It allows manipulation of a set of properties such as height, width, line colour, text alignment, and many more. CSS was developed by the World Wide Web Consortium (W3C), a body which maintains international standards for the web.

In recent years w3schools.com has become an invaluable resource for new web devs to start investigating the tools they use. W3schools is in no way affiliated with the W3C but has become the default landing place for new comers with it’s resource pages and easily digestible code snippets. When searching CSS usage and keywords it’s hard not to end up on w3schools but the Mozilla Developer Network (MDN) is considered a advanced resource for more experienced developers. I mention these organizations because they are the leading providers of CSS documentation with the exception of the difficult to understand specification offered directly from W3C.

Now that we understand what CSS is and where to go to find details let’s consider the following example code with no styling added:
<div class='container'>
<div class='row'>
<div class='col-md-6'>
<button type='button'></button>

The scenario is fairly straightforward, there is a specific control, with id Dataview, on the page which will view the data to be displayed on the page. Into the Dataview DOM object we will add the above code. A div container to encapsulate everything, a number of div rows each containing a number of div columns, for the sake of this example we’ll be building a 2×2 grid, and in each grid cell a datum. Some of you may recognize the classes as belonging to the Twitter Bootstrap framework (or similar frameworks like Skeleton) but that has no impact on this example. During development it became apparent that navigation controls would be required. Our task today is to turn one of the grid cells into a control panel with a back button to begin with.

As you can see we’ve used the height and width styles and either indicated a value relative to the parent or to inherit directly from the parent element. This may seem almost too easy but the nuance of inherit is what brought us here today. First let’s review the documents. w3schools has little to say about the inherit property “The inherit keyword specifies that a property should inherit its value from its parent element.”[1]. Still curious I looked around a little more and found that the MDN had a little more precise information “The inherit CSS-value causes the element for which it is specified to take the computed value of the property from its parent element.”[2]. They key word here is “computed” and let’s break down the above snippet in detail to understand why.

Remember, this code is a snippet of a 2×2 data grid. The top container inherits the size of what contains it, meaning that the “container” div is the full size of the parent element. The “row” div should be the full width as the parent but only half the height to allow room for the second (not featured) row. The “col” div should be the same height as the row but the width divided across all columns, once again half. Lastly the button should fill the column that contains it. That is NOT what the above snippet does. The above results in columns that are only 25% the height of the total container div and the button is far too small (height of 12.5% and width is 25% of the total container). Why? Because inherit does not inherit the computed value but instead the actual style property.

With this we can see that the column would have a height of a quarter of the container. The button would have a height of half of that. Clearly this isn’t what we set out to do. And while the w3schools definition remains sufficiently vague to not really address this problem the MDN definition seems completely backwards about using the computed value. So far I haven’t been able to discover exactly why this happens. I was lucky in that my framework was still very simple when I encountered the issue and it happened with nice easy to visualize values. This may just be typical of the web development process though, so much to learn and so little to rely on.

Now that we’ve replaced inherit property with explicitly 100% of the parent property everything displays the way it was meant to. The column div is the same height as the row div (which is in turn half of the container) and the button is the full size of the column.

Web technology allows us to explore amazing ways to transport and display our data but the reliable documents can be few and far between. It’s more important now than ever before for developers to be not only technically capable but also creative and resourceful because in the world of web dev sometimes the only solutions that exist are the ones you make.