Externally, we work as a consulting company. Internally, we act like a research lab.
Our goal is to make the inside of software systems explainable. We believe this is achievable by affecting the way we look at systems. We regard software engineering as being primarily a decision making activity, and we treat tools as being essential.
We contribute two things towards our goal. We invented moldable development, a new way of approaching programming through the lens of custom tools. And, to show how this can be practical, we are developing Glamorous Toolkit. All this work is free and open-source under MIT.
Tudor Gîrba authors the humane assessment method which pioneers the idea that software development should be regarded primarily as a decision making activity, and shows how systems can be made explainable through systematic construction of custom tools.
The first incarnation of the Glamorous Toolkit inspector shows that individual objects can be visualized in practical ways.
After intensive applications of software assessment in industry, Tudor’s work receives international recognition through the Dahl-Nygaard Junior Prize. He is the only recipient of the prize acting from industry. His acceptance keynote puts forward the concept of software environmentalism.
feenk is co-founded by Ioana Gîrba and Tudor Gîrba and takes on somewhat odd, but ambitious customer projects.
Andrei Chis defends his Moldable Tools thesis and joins feenk.
Aliaksei Syrel joins feenk. The work on the new generation of Glamorous Toolkit starts.
The first public demo of moldable development. Moldable development is a generalization of humane assessment, and the demo provides an overview of its applicability.
The first beta version of Glamorous Toolkit is set to be released.
We fund ourselves through customer projects. These can vary in both size and form.
On the one side of the spectrum, we work with teams having to deal with large legacy systems that are considered difficult (and often impossible) to move forward. Typical problems take the shape of either strategic assessments, or of steering agile architecture. A strategic assessment is required when the team faces a broad decision, such as migrating to a new technology, adopting a new architecture, or evaluating the path to perform a crosscutting change. The steering agile architecture scenarios relate to teams that want to internalize the ability of making informed architectural decisions and evolving the system in a piecemeal fashiob. The two often co-exist: a strategic assessment is often complemented by the need of steering the technical work to reach the goal.
On the other side of the spectrum, we work with startups to help them innovate faster. We do this by materializing the domain in code that acts like executable specifications in that it is visualized in a way that non-technical people can evaluate.
While these problems are typically considered radically different, we approach them uniformly. For all these projects we use exclusively the same tools and technique we create. There are two reasons for it. First, we believe our tools and techniques provide unique abilities. Second, applying the same tools and techniques to a broad range of real-life scenarios provide empirical evidence supporting the generality of our research.