Too often, developers drill into the sea 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. And software is more than code, too. Configuration, logs, data are part of it as well. Once you see it like that, you will want tools to deal with it. In this talk, we show live examples of how engineering decisions can be made quickly by building custom analysis tools.
Target Audience: Engineers, Managers
Prerequisites: Technical experience with at least one larger project
You will learn:
The main goal of this talk is to show a different and practical facet of how understanding software systems can look like.
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 sea 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. This shows that assessment involves a small set of analysis skills that can be utilized in many different situations.