Thursday 7th April, 2016
9:00am to 10:30am
Too often, developers drill into the see of data related to a software system manually armed with only rudimentary techniques and tool support. This approach does not scale for understanding larger pieces and it should not perpetuate.
Software is not text. Software is data. Once you see it like that, you will want tools to deal with it.
Developers are data scientists. Or at least, they should be.
50% of the development time is typically spent on figuring out the system in order to figure out what to do next. In other words, software engineering is primarily a decision making business. Add to that the fact that often systems contain millions of lines of code and even more data, and you get an environment in which decisions have to be made quickly about lots of ever moving data.
Yet, too often, developers drill into the see of data manually with only rudimentary tool support. Yes, rudimentary. The syntax highlighting and basic code navigation are nice, but they only count when looking into fine details. This approach does not scale for understanding larger pieces and it should not perpetuate.
This might sound as if it is not for everyone, but consider this: when a developer sets out to figure out something in a database with million rows, she will write a query first; yet, when the same developer sets out to figure out something in a system with a million lines of code, she will start reading. Why are these similar problems approached so differently: one time tool-based and one time through manual inspection? And if reading is such a great tool, why do we even consider queries at all? The root problem does not come from the basic skills. They exist already. The main problem is the perception of what software engineering is, and of what engineering tools should be made of.
In this talk, we show live examples of how software engineering decisions can be made quickly and accurately by building custom analysis tools that enable browsing, visualizing or measuring code and data. Once this door is open you will notice how software development changes. Dramatically.
One question still remains: How much of an investment is it necessary to get to the point in which building these tools is cost effective? To address this, all shown examples make use of the Moose analysis platform (http://moosetechnology.org) - a uniform and compact platform for software and data analysis. This shows that assessment involves a small set of analysis skills that can be utilized in many different situations.
This main body of the session consists of a succession of examples, including live demos. These make use of the Moose analysis platform. While this is indeed a concrete platform, the goal is not to sell it (even if it is open-source), but to use it as a teaching device. It is precisely because all of these use cases can be dealt with through the same (small) platform makes the point that indeed software assessment is a discipline involving a small set of skills worth investing in.
Start from the problem of reading code. Provide this simple example: suppose a system contains 250’000 LOC. If you read rather fast, you might be able to sustain a reading speed of 1 line in 2 seconds. If you do the math, it take about 1 man month to read the whole thing. State that reading does not scale and start a dialogue on possible alternatives.
Move to concrete examples (the order and content of the concrete examples can change depending on the dialog with the audience).
Quick intro into Moose.
Start from some code problems to identify contracts in Java code involving dependencies and usages of annotations. For example, see:
Switch to another class of problems involving searching through the file system and extracting a desired information out of XML. For example:
Switch to yet another problem related to searching through a DB and visualizing some aspects of the data. For example:
Wrap up: Take a step back and:
— Note how all these highly distinct use cases are done with a uniform and small set of tools. This shows that an investment in a small set of skills has high potential of returning that investment.
— When tools become to cheap to matter, assessing software systems can change dramatically. This is important because we spend most of our energy figuring these systems out.
— Note how assessing systems has a bad name. It just is not perceived as a satisfying experience. This is fundamentally wrong in our industry and we need to change that. Assessment has to become a beautiful experience. And the first step is to understand that reading code is not at all sufficient.
— End by noting that developers spend most of their time understanding systems and this is currently spent through reading. This means that this is the single most expensive software engineering activity. At the very least, we should at least talk about it.
As an example, a similar talk (but shorter and with other examples) can be seen here:
This talk is addressed to engineers and architects that have some experience with understanding larger code basis.
Get a novel perspective on how to approach detecting problems in code bases by crafting custom tools.
Sign in to add slides, notes or videos to this session