>> Andrew Begel: So I'd like to introduce Yvonne Dittrich. She is a visiting researcher, visiting
the Vibe Group for another six weeks working with me, Andrew Begel, on the Studying One
Microsoft. And the Yvonne is a professor at IT University of Copenhagen in Denmark, and she
does a lot of work in qualitative empirical studies of software development and software
engineering; and she has worked in the past the University of Hamburg, she's also been at IT
Madras, IT Mondi in the last couple of years in India during a lot of globally distributed software
development studies. And the first time I heard of Yvonne she had been talking about her
dissertation work where she had software developers go to group therapy to learn how to talk
to each other properly, and that just seemed so incredibly awesome and I just want everybody
to do that. So everyone’s dysfunctional; everyone could use some therapy. But now we're
going to have some, she's going to talk today about some software engineering ecosystem work
that she's done in the last year or so, or the last couple years at, in her job as a professor. So,
Yvonne.
>> Yvonne Dittrich: Thank you very much, and thank you for inviting me here. It's a pleasure to
meet all the people here at Microsoft Research. Yes; and actually this is a piece of research that
has been going on that I would like to present to you today. It has been going on for a while
and it's called Software Engineering Beyond the Project. We all, when we talk about software
engineering we all take for granted software engineering takes place in projects, wouldn’t you
say so? So that's what we're teaching, what we are planning for, what messages are
attributing.
So what is a project? Well, these are a number of definitions. We don't have to go read them.
Kind of when it breaks down there's a number of characteristics of a project. So a project has a
predefined outcome, a goal. Even if it's not exactly specified there is some idea that should be
a product afterwards. It’s normally said to have a beginning and an end. It has limited
researchers, there's not kind of, there is a limited number of people working at it for a limited
time, and it consists of a number of tasks and activities. So that is in the definitions that the
software engineering community provides for what a project is. But what if that is not the
case? What if software development takes place in a different way? And what does that mean
for software engineering? So that is what I would like to talk about today.
And I will start with some very, very [inaudible] research where I started to get my doubts
about our perception of what the discipline is about. Then I will repeat the main part of the talk
while looking into software products and that is probably very relevant for Microsoft because
Microsoft is working with software products. That's more or less what you're doing. And then
in a way, what does that mean then afterwards for software engineering? What are the
questions? If the project is maybe not the main entity of the activities or the main way of
organizing the activities we are supporting what does that then mean for software engineering
as a discipline? What are the open questions here?
So I will start with some beginning doubts, and that was in the late 90s when I started to do
research at [inaudible] Institute of Technology after my PhD. We were actually starting to work
with the government, and as I came in as a software engineering researcher I thought okay, I
would like to talk to the engineers and to the designers. So we talked with people from a onestop shop and that was in a time when Sweden, the municipality administration got
reorganized into, so that you have a one-stop shop where citizens go and about 95 percent of
all the issues were taking care for there. And it was in this reorganization that we asked, and
we asked the head of the one-stop shop of a small municipality in southern Sweden, and she
said well the designers, that's us, are kind of like, took me a bit of time to understand and to
appreciate that statement because I thought kind of the designers that's where the computer
scientists, that's the technicians, that's the people who are actually doing the things, the staff.
But if you started to look at the development of technology from a use context perspective you
suddenly had, the technology was only part of what was there to design. So we started to call
all these people and local designers. These are the one-stop shop people at, it’s all this work,
we’re a part of that. So on the one hand they developed software with different developers
they hired and their own IT people. On the other hand they kind of discussed with the back
office people about what the service provision. And of course by introducing computers into
service provision you have the citizens coming in and you have to negotiate what does it mean
to provide municipal services now partly online. So if you look at that then you have different
things that get designed and you have to find foci of design. And of course not all the design is
about technology in the narrow sense, but it might be technology in use, how we are actually
deploying technology to both provide better services. How does the services change for that?
And one of the things that came about when you look at the software development from this
work infrastructure perspective you had no clear defined projects, but you had a diversity of
interlaced practices of design and use. So you had projects where people were developing
specialized software; you have products that were customized, configured for a specific
context; you had the development of Internet which was both context development and
technology development and all that work kind of going on at the same time.
So I started, I also thought kind of okay, well there's some software engineers. And if you hear
municipal administrators talking about software engineering I've seldom heard people being
that derogatory about software engineers as they are. The main providers are actually
providing software for the whole government so they have a much bigger picture and small
municipalities are not in their focus. So they were kind of not very, not liked very much.
But then I thought kind of like well, but you must have some people with whom you are like to
work as software engineers, and they pointed me to a five person company selling an off-theshelf booking system. They had set in a very strange place, nearly a village from an American
perspective in southern Sweden in the woods, of these five people actually two were
developing the basic software. The two and two others were customizing the software for the
specific municipalities but they had customers all over the place. They have over 300
customers, that means municipalities using their software in southern Sweden, in the whole
Scandinavia, Finland, Sweden, Denmark, and Norway.
And we looked at their development practice, and at that point in time the HL Manifesto was
not out yet; so we called this, what we saw, HL practices. So they themselves, they said oh,
we’re doing it, kind of we know that we are not doing the software engineering way of things,
but we are actually getting things done and we don't, we manage to get our report line at a
time that we use on report, support we get that down. So we looked at how they actually
developed software; and they released 20, they had 20 releases per year. Most of these
releases were very small upgrades. About once or twice a year they had a bigger release, but
you actually had to change the database, so the database scheme. So they had kind of bigger
installation scripts underneath.
And that was the first time I thought kind of like where is the project? They have been doing
that for 10 years at that point in time, 10, 15 years. And they were kind of like continuously
supporting the software and continuously releasing the software; they were happy with it.
They enjoyed actually new challenges now and then. So they were moving from a very oldfashioned database to a SQL database. They were moving from, they were moving actually
with that, they were moving to Java so it was not high-end technology. They were happy with
it, the customers were happy with it, the users were happy. So this is somehow a different way
of developing software than what I expected to see in this situation. And that was also the first
time I started to practice of the development of a product. And then over the time I did more
empirical research and I saw the same pattern again and again and again. And that is what I
want to talk about today and the implications of that.
To define software products, software products are programs that are developed to be used by
more than one user and or customer and often need to be configured and customized for the
specific use context. I distinguish between configuration and customization. Configuration is
through predefined interfaces like, for example, the definition of filters for email readers,
clients. Customization is when you actually start to mess around with the code. In many cases
you can do both. They are used over an extended span of time and they are continuously
updated to match the evolving needs of a market. So that is our definition for that.
These are examples. For example, Microsoft Word is a product. You can actually configure it,
permanently change its behavior through a configuration interface, but you can also go down
to the programming name which the macros and exchange the macros. So you can actually
develop your own word.
Over the time I did research with several companies; and I will talk about these four products,
four cases in more depth. So we’ll come back to them again. I'm using a similar figure as for
the diversification of the design and the use context from the perspective of the use context to
look at what we started to call ecosystems. And this one is one of the things that we are talking
about. This is Dynamics Nav. At that point in time there were a few years before the research
they were acquired by Microsoft. What I'm describing here is the boxes are organizations or
companies. The people in there they are groups of developers or users, so they are
stakeholders. The arrows mean the corporation around the design of some kind. And here you
have multiple organizations. So that's the notation.
How I did the research, the thing is that I actually recognized this common pattern after a
number of research projects with these software products companies. So we've done a lot of
research mainly together with PhD students on the individual projects, but they all focused on
different areas. So how do you then kind of, you know that there is something that has
something in common, but how do you actually make that accountable in a scientific way? So I
went back and did interviews with the partners and with the people in the companies we did
the research with. So it is an interview study; it's based on the three interviews per company,
and it's with open coding, actual coding. That's how I derived a theme so that I came to talk
about; and it's based on and triangulated with previous ethnographical fieldwork and long-term
contact. So one of the companies is actually people that I know for 20 years, they are friends
and they run a company on developing a software product.
The triangulating fieldwork is a documented in a number of articles. I don't have time to put
them up for reading now, if you're interested I can provide the slides and you can follow up on
some of the themes. However, that is the documentation of the underlying empirical work I
based the interview study on.
The first product I would like to talk about, and I'll talk you through that with a bit more detail
because you will see that makes it also easier then to follow the analysis because it's pulling out
the commonalities between this ecosystems. That is UIQ. UIQ is a daughter of Symbian, the
Symbian Company. You might know that Symbian OS was founded to counter Microsoft phone
initiatives as a joint venture by Siemens, Motorola, Ericsson. They were founded actually in
Blekinge, that is close to the university I was working at the time, and we did research with
them. We did research focusing on interaction design and user experience with the interaction
design group in this company.
So UIQ was, then at some point in time Symbian was a split up into Symbian OS and UI
framework on top of the operating system. So the Symbian OS was moved to London also to
have more people, be able to hire more people, but UIQ stayed in Blekinge. What they did,
they did a user interface framework. They developed that in parallel with specific applications
for the customers that were also the owners of the company. And that is interesting because
you all know Nokia was buying out the others and made Symbian and UIQ the software open
source and that killed the company. So you could think about it as an ecosystem because
actually if you changed it too much you might actually destroy it.
They developed their product, their framework they developed in parallel with applications
based on it. They developed, these applications were done [inaudible] and kind of further
beautified by the customers and owners and then there's the users here. You have, on the
other hand, you had third-party developers who also, they were not so prominent as users and
customers and that was maybe one of the errors that the management did here. On the other
side, they incorporated a high level of Symbian because the user interface framework was
depending on functionality from the operating system.
The second tier is innovation. Innovation is developing in ERP systems. ERP systems
traditionally came with their own proprietary database and their own proprietary language
development environment. That is still the case for innovation. At the time of the interview
they were actually slowly moving the technology stack implementing as the database and the
implementation of the proprietary language and the runtime system over to Microsoft
technology. For that, that was in the beginning of the interview, I wasn't really aware of it, but
that they actually had to communicate and drive requirements into the Microsoft organization.
And they didn't discuss very much about it. So for that they had too much pains.
These ERP systems, I said that there's these frameworks and proprietor languages, databases,
runtime systems. That is done by, they distinguish between two groups of developers,
framework developers and application developers. And the framework developers, they are
responsible for this backend side of it. And they say there's different kinds of developers.
There is different types of developers. So these are people who are kind of really interested in
compiler construction, performance, very hard technical stuff. Application developers are, have
often a business background and they are, they know about the domain. And that is the
administration of all the data in the company. So the idea of an ERP system is that you run your
whole bookkeeping administration accounts, human resource, through the application.
Opposite to other ERP systems the idea here was not as a division and except targeting smaller
companies then, for example SAP who is the high-end product in the market, and that meant
also that they said okay, we are providing basic functionality but they are opened very quickly
for partners to not only configure the software but to actually customize the code. So the ERP
systems are shipped together with the development environment for these people to actually
program. These customizations can be changes in the business rules but it can be so-called
verticals. That means they're developing a whole new module, for example, a module for a
specific business area. We had one partner, they were developing for a small airplane carrier.
They developed a whole module about what is a flight and what are seats and tickets and pilots
and attendees? So this means that you do a vertical, so you have changes in the database, you
do a piece of program that has some interaction with the base program, and then you do the
interface on top of that. And of course for that they are communicating very tightly with the
customers here.
The next thing is also they were also fun. They were a company doing hydraulic simulation for,
that's actually the nicest pictures in my sideshow. What they're doing they're simulating water
flow and they have one-dimensional, two-dimensional, and three-dimensional simulation
engines and they combine them sometimes. This is Canberra, Australia; and do you see kind of
a river here? It's not exactly under the blue line but, so what you do is you're abstracting the
topography of a water system. You identify sections for the model, you use the sections and
you define how the riverbed looks like. You have rainwater, runoff system models there, and
based on that then you run simulations, for example saying if you have heavy rainfall how will
the water in the river behave, when will it flood, things like that. So you can also simulate, for
example, what happens if a dam breaks?
The company is one of three or four worldwide leading companies in that technique. They have
been modeling the Nile system, for example. That's also one of the things I learned, the reason
why Egypt has a big military. They are so much depending on the Nile so they have to be able
to protect their water sources. So that is one of the motivations for them. Anyway, I should've
doubled that slide.
So at the time of the interview they were reorganizing their organization. Previously, the
simulation engines were maintained and developed by departments focusing on certain
modeling tasks. So their main business, as their main business they regarded consultancy for
governments and for other actors[phonetic] about impacts of constructions on the behavior of
the water, on the behavior of oceans or rivers.
So they had the engines and the software maintained close to these consultancy groups. They
recognized that was not, on the long run this was not actually a sustainable way for the
software part of it, and they wanted to sell the software more independently than before. So
they started to develop a software in an own unit, but of course these people in this software
development unit they were tightly interacting with the people using the software for these
specific consultancies. On the other hand they were developing not only that the people here
were configuring or kind of defining the simulation models that were run by the systems they
were also, when you found a kind of element, a simulation element that was not yet supported
by the system these people had hydraulic engineering education so they might have a PhD in
applied mathematics, so they all could program. So they actually all added to the code base
which was also an issue because it meant that the code base developed sometimes in a pretty
uncontrolled way.
However, these people in the city, when we kind of did the research with them they started to
develop another set of customers where you had kind of permanent simulation of water
systems in order to manage the water system at the same time. So they would actually
continuously say okay, if we have so many rain then we might actually have flooding in two
days in the city. So that means how can we prevent that and how come we work with that
ahead of time? So that was the water management solutions where you did not want to ship
report to the customer but you shipped the whole system, operational system to the customer
and of course the other users who used the software as well.
The last system is a very different system that is a system administration tool. Here, it is again a
very small company who on the one hand did system administration for governmental
organizations in Germany. So they had their specific customers and they kind of, in order to do
the system administration they had the need to have an automatic distribution and installation
tool for software in the local area network. There are industrial solutions for that. I'm counting
on that some of, one of the solutions might actually be produced here. However, they are very
expensive. They don't work for small organizations. So they developed, and then thought
okay, well kind of let’s do it ourselves. So they developed an open-source product that they,
together with the customer, they first developed that. However, as it was an open-source, of
course other people can use it.
Here again we have to the basic software but to run the software you need installation scripts
for specific programs on specific operating systems and specific hardware. And these
installation scripts they were of course done by them but they were also done and shared by
the open source community. On the other side, with this tool they shipped a UNIX kernel. So
every time the UNIX kernel changed they had to change. And also every time the operating
systems changed they had to change. So one of the big projects was to make this system able
to handle Windows Vista because that obviously worked very differently from the previous
Windows versions.
So, yes. So now kind of why did I talk you all through these kind of different cases and different
examples and what can we learn about them? One of the main things is that if you look at the
series of ecosystems, in none of the ecosystems there was, the development took place in one
place. So there was, so the final design, the thing that was a surrounding here with the user
that was based on one hands the direct communication with the people installing that system
here, but that, again, was based on some other software and sometimes the chain here like in
an innovation chain this was actually much longer. And each of these stages added to the final
software. That means you have to think about an interlaced system or kind of related system,
communicating system of different designed constituencies. What happens here on the use
side is depending on the processes and design decisions taken far away from the user so it's
also difficult to influence this. So I'm also into user and design and development of software.
So a lot of the usability methods that we are actually teaching they kind of take for granted that
the [inaudible] system, so the software engineer then developing the software has actually is in
charge of the design. But that might not be the case.
In all places for that reason one of the things that was identified as most problematic was the
communication with the user and with the user community. And all the companies did extra
work to be in touch with their user organization. So here in innovation they had big
conferences, worldwide conferences where they invited users, partners, introduced new
features, discussed new features with them. Here they had the same thing. They had
companies, conferences, user conferences where they also tried to identify new features, new
directions to go to. UIQ had their own user group because where they did long-term studies of
the usage of certain applications and features in the phone. So in other words, as it is not clear
who exactly is the user and you're not cooperating with the user you have to, so there's a
different way of interacting with your user community.
>>: Sorry, can I ask>> Yvonne Dittrich: Yeah.
>>: Clarifying question. When you talk about users in this context does each group talk about
the user one step down the line, like the framework developers, users of the application
developers not the customers? Is it that kind of user or does everybody realize the end
customer who actually pays money is the user?
>> Yvonne Dittrich: Everybody is pretty aware that the end customer is the main user. And
these are the people who are paying the show. So all of them are kind of getting into this.
Here, what comes from a usability point of view, here is, so the usability work at this product
development has to take that into account that you're not actually developing for a specific
user but you're developing for a whole group of users. And I think that actually Microsoft had
the most advanced system in place here, but also UIQ was not that bad. They were also very,
very good. The other thing is, from a software engineering point of view, you have actually a
situation where you have a use before you have a design. So there's people using the software
and who are acquitted the software who actually know what the software can do for them. So
have also a different level of interaction with the user. You're not developing from scratch.
From a product point of view, and that might be more interesting also from a technical side
here, you need technologies that supports both of the evolution and the deference of the
design. So the design is deferred to use context and you can say like okay, well what does that
mean? We have a lot of technologies that support kind of the rationalization or generalization
of design. We have aspect [inaudible] development we have tried, we have model driven
development, things like that. However, all of these kind of technologies are focusing normally
on having software engineers as users. However, if you do it like that you don't have
necessarily software engineers as users in these ecosystems. You might have software
engineers as users, you might have business people as users, you might even have people who
have no software education and no technical education as somebody who's actually configuring
the software.
So in other words, the challenge here is to make these technologies, to lift them up to the user
level, to main expert level. The other thing is that when you kind of combine evolution and the
deference of design, especially if you have to allow the user to change your code, your source
code or the source code of the application, then you get problems with the upgrade because
you have a two-dimensional evolution of the software. And that is still an unresolved issue
because the techniques that we have for that they work when you can anticipate at exactly
which kind of places you will have a change, but they don't work when you cannot predict
which kind of places will change. A colleague of mine who is into programming languages, in
the beginning of some of the research underlying it he said [inaudible]. They just have to use
our technologies. In the end, two years later he wrote an article together with one of the PhD
students detailing how all the technologies from the scientific community fall short in
supporting, for example, ERP customizations in this respect.
What you also have is the end user development interface that is here for customization and
configuration. That is only one of the technical interfaces between the design constituencies.
So also the interface here, for example, between on one hand UIQ and Symbian and [inaudible]
it that here somehow the interface works in API. This was also an API. So the interface, the
technical interfaces, they are separating and breaching between different design
constituencies. And these interfaces are contested because you want to do the development
here sometimes they kind of reported about that they didn't have the resources to develop a
specific feature. These guys wanted it, so they developed it themselves because they also have,
and at some point in time they were saying well kind of, anyhow we have this bit of code here
that every time you change something here, and that is rather frequent, we have to change
with it. So this actually should be maintained here. So they shipped code between companies
and they did the same here between UIQ and Symbian. So in other words, these interfaces
have to be carefully also maintained over time.
And last thing is as you have these multiple level evaluation on all the companies worked you
thought kind of they should have a high level of architectural documentation; they didn't. They
worked with what we called a walking architecture; that means people who have the
architecture in their head, and walked around. And they were, and we discussed with them,
why don't you just write it down? Why don't you distribute it? Why don’t you have a website
explaining your architecture, especially with these big ones where you had a huge number of
people developing the software. Innovation that point in time there were about 200 people
developing the software. They said well, as of as one of the PhD students working with the
architecture in the project she did an interview with a number of randomly selected, but she
wanted to a fair, to the [inaudible] in Germany and kind of talked to people and had a number
of different, did interviews there and what came out of it is that one of the reasons why the
architects were reluctant to put down the description of the architecture is that then the
developers would use the architecture without consulting them, and that meant that they
wouldn't get an update about what were critical aspects in the software. So they used, in a way
somehow they used, we called that in the article good architectural reasons for bad
architectural documentation. You had a question.
>>:. It's interesting, I was thinking about the way that you talked about the interfaces between
each group and that what we learn in school how to evolve your APIs you think [inaudible], you
make a subclass or you make an interface, and then you just add interfaces for extra
functionality but you try not to delete old functionality. But the notion of being able to sort of
change the boundary, where the functionality is at all, like the API it’s here, well, actually it
needs to be pushed further up this way and this one needs to be pushed back; it's almost like
web design in that you have to decide whether to put things in the client, the mid-tier, or the
backend server and the division sort of changes as your performance characteristics change.
Are there sort of established, I don't want to say formal ways to talk about that kind of
architectural evolution or is it just a negotiation between parties? I'm just kind of>> Yvonne Dittrich: I haven't encountered any formal way of this kind of negotiation on an
architectural level. But in the cases it was a negotiation and it is still a negotiation. So with Nav
they had to say like okay, that's the database, that’s the SQL database. Does it do what we
want it to do, or do we have to do some add-ons, or are they doing add-ons for us, or do we
keep our proprietary database? So in a way somehow there's a problem and there’s many
solutions. That's why you call it design also.
>>: The negotiation route leaves a big problem where the customers don't have, there's much
more organizational friction between customers negotiating with Navision and Navision
negotiating with the rest of Microsoft, at least Navision was owned by Microsoft so they could
at least call them up on the phone and actually find out their e-mail addresses whereas the
customers can't. And so like their power to move the boundary isn’t as, they don't have as
much power.
>> Yvonne Dittrich: Kind of yes and no. But they negotiate about something else here. This is
not all friendly relation because in a way these people are earning money by doing special
features. So if now Microsoft gets interested in implementing the special feature in their own
software then they are losing business here. So in other words, if you have a negotiation of a
different kind of boundary on that side.
>>: Or is this the corporate purchase?
>> Yvonne Dittrich: Yeah. So sometimes, actually I think Navision, I don't know whether they
did that after they were acquired by Microsoft; but I know from before they actually bought,
sometimes they bought the software from the partners to make it part of the main application.
And that was also more interesting when we did interviews with these people they kind of also
tried to make, that was in the time when they changed the proprietary database to the SQL and
with the SQL database you couldn't do certain things as a partner. So they had a proprietary
database had a very smart indexing system so you could do very quick searches and reports. So
they were kind of trying to lobby through us to get back to the proprietary database. So that
was, so I want to say with that is that these are negotiation points of who is doing what in this
context. And at the same year somehow what can an internal IT department do or smart
super-user and when do you ask a cosidence[phonetic]. Cosidencies[phonetic], they are taking,
I don't know what a cosidence[phonetic] in the US is taking, but I think it's in about 1000 Danish
crowns which is 150, 160, 200 dollars. So it's quite an amount of money or so.
So, there is also competition between these guys. On the one hand they have the same kind of
interest with Microsoft; on the other hand, they are competing for the users, for the customers
here. And they are somehow taking each other's customers because its introduction of ERP
system is normally related to a high friction in the organization. So after their first
implementation many companies tend to switch their considents[phonetic]. So there's also
kind of, it's not that you incorporate around the design doesn't always mean that you’re nice to
each other. With other words, when we were discussing this kind of multilayer development I
think there's also another point that we don't really, in the proclaiming technology, we don't
have concepts for this multilevel development. Well, we have concepts but they are often not
working for these real world application contexts.
The last one is the process. And that was actually a surprise. It was pretty, I knew that there
was kind of this continuous development, but when I started to do the interviews all of them
said well yes, we have, one of them called it the heartbeat of the product. That is where the
new features are released. So that was kind of like a studied pace and it was kind of
characteristic for each of the products. So they had a heartbeat of half a year, so every half
year they had a new release with new features, things like that. There were also three
developers working on it so was not a big thing, big company. The ERP systems, they had at
that point in time a three year release cycle and they were about to bring it down. I think they
are down now with one year. However, whatever the characteristic heartbeat of the product
was there was one cycle that was quicker and that was back fixing or small features, patches.
That was about one tenth of the time. So if you had a half year release cycle then the patches
were every week, every two. When you have three years release cycle the patches, the back
fixes were every two or three months. So you had kind of, it was kind of like the work kind of
relationship but we didn't put numerics on it.
But then there was another cycle which we actually which I discovered in interviews and that
was because you had these new features and the features were not anticipated in the
beginning, so often, the technical design, the architecture did not actually support these
features; so over time the technical design got worse. So in the regular base they had to renew
the technical design and that was normally across several of the heartbeat releases. So when
Navision was replacing the technology stack with Microsoft technologies they couldn't put just
a three year release just on changing the technology because then they wouldn't have been
able to sell anything anymore. So what they did is actually they sliced in the transfer to the
Microsoft stack over several of the releases. Here the smallest, the open source, that was every
two years or every three, four years they had to redo, for example, their data structure because
the new operating systems, the new features, new operating systems all that was, kind of got
into the way. Okay.
So in other words, there's also different drivers for different development cycles. They roughly,
we had this research and maintenance and categorization of maintenance. They roughly
correspond to the three maintenance categories, back fixing, new features. Corrective,
complementary, and proactive maintenance. How to organize such a process is contested. So
there were a lot of discussion. Microsoft had different organizations depending on the kind of
release. When it was a feature heavy release they had feature teams; if it was like a backend
heavy release or an application heavy release they put the framework changes in the beginning
and then kind of as you get them out of the way, get them done and then focus on the
application level.
UIQ was experimenting with feature teams and module oriented teams. They were
experimenting with splitting maintenance from development. And as I said, UIQ did simulation
software. This company was reorganizing in order to be able to focus more on the software
and not so much on the application. So one of the points was that you had to keep track in
what happened in the other, these end constituencies because what happened here in the
partner space will tell you something about what is new features here. On the other hand,
what happens here at Microsoft will kind of tell you whether you get into problems in the
future. So you had to actually keep track with these things.
So what our project’s done in this context, you could say it releases a project, but the release is
not a project because it's not from scratch. And also it's not as closed. In these companies
what they did organize as projects sometimes was these changes in the technological base. So
they had a project going on in parallel to the evolution restructuring the main data structure or
reworking the main data structure. In the simulation software when they actually moved one
of the computational kernels from a [inaudible] program to, I think they used C sharp in the
end, that was kind of the whole restructuring, the rework of the kernel that was a project. So
what you have is that the project is kind of a temporary closure that you do to do certain kind
of technological, to have peace and quiet to do a piece of design in a good way.
So that is by far not the only, not the main way of organizing here. So, that's kind of coming
back as summing up the results. There's no single project but an interlace of development
activities. Requirements are moving. So even during the release requirements are moving all
the time. They cannot be regarded as fixed but are subject to multilevel feedback cycles that
you do not control as an organization. There's no one process but a continuous development of
several rhythms overlaying each other. So it's more than HL development in that respect.
Software is not necessarily developed before it is used, so sometimes it's used before it's
developed. That means. [inaudible] have to take social and technical heritage into account.
Architectural knowledge and knowledge management needs to support continuous evolution.
And that means also if we know what we want to have architects in this context do
architectural diagrams we have to actually support them with keeping up to date with problems
in the code base so they can actually continue developing their architecture. And there's no
blank slate; never. And that is confirming something that Lucy Sedgman said in another
context, that we cannot design as if we come from nowhere. We also always have to, in this
context specifically, we are always basing our technical design on something that is already
there and we have to take that heritage into account.
And what does that now mean for software engineering? Many software engineering methods
and tools are based on the notion of a project and we might have to reconsider that. We need
to cope with interlace of the heterogeneous development and use activities and how we
actually make use of the possibility of getting feedback about needs and wishes and how things
are used in the continuous development cycle. And that means also we should actually start to
support design collaboration along the chain of design, not only within a project, but along this
chain of design constituencies.
From a use side we have to think about coming from ease of use to ease to ease of design.
Most of these applications can be configured by the end user and end users are willing and able
to do that. They need good user interfaces for that or good designer interfaces for that. That
requires that we actually think about, when we design software product we should not to think
about designing the functionality but we should think about designing environments for
somebody else to design. And for that we have academic tools and languages that are solving
some of these problems or providing us with tools for that. However, they need to develop to
fit the reality of software product ecosystems. And that means we cannot ask, for example,
people at the partners to use formal methods as formal methods. lf we want to have formal
methods on that level we need to make it more usable. And we need also to allow, as we need
to get a better understanding of requirements for such tools and languages and especially what
does it mean to open, to use them to provide end user development interfaces for
nonprofessional developers.
Yes, that is the last slide. And the question anyway, Andy and I were doing the last two weeks
we were talking to people here in Microsoft and understanding the reorganization, and one of
the reiterating things that came about is kind of, when we are deploying things on the cloud
things get different. But what gets different? It's not different that we have users and it’s not
different that we have software products that are configured and that we are depending on
other products, however it seems one of the things that I would say as a hypothesis that the
processes, development processes and the deployment processes, they are the notion of the
release starts to disappear. It's going to us continuous deployment. What does that then mean
for the corporation with the other actors in the ecosystem, especially the users? And how can
we support this continuous evolution on multiple levels? Because just I'm kind of changing the
operating system does not mean that I change the services based on it or that have stopped
changing the services based on it. So we have even more challenging dynamics in these
ecosystems. So, thank you.
>>: Comments or questions?
>>: So what’s been surprising with this set of interviews that you’re doing [inaudible]?
>> Yvonne Dittrich: One of the things is that if you have these even more challenging dynamics
that operating systems don't take three years but one year releases, one-year rhythms, it
becomes much more important I think to have an understanding about what are the features
somebody else have to deliver so I can deliver my feature here? So anyway, I think the
tendencies that I described here and you could say is based on all technology, they get more
extreme in that respect. So you have to be much more knowledgeable about what the
operating system is doing in order to build the cloud based on it, what the Windows servers are
doing in order to base the cloud on it in order to be able to deploy software based on it. So a
lot of things I would say are the same or I kind of see it again with this kind of challenge of, the
challenge of you have a requirement, you want to do certain things, but that means that you
are depending on somebody else to do certain things and how to then negotiate this, but in a
way somehow in a more fast-moving environment, in a way even more important.
>>: Yeah. It seems like dependencies, so what you're talking about [inaudible] where
everybody's intimately interdependent and what the product program [inaudible] is paid with
dependencies.
>> Yvonne Dittrich: Yeah. That is one of the things because that is what we have been taught
in the university that you have your requirements and you fix them and then you develop your
software and everything else is a problem or is a defect. You haven't done your requirements
right if they change. So that is what we have been fed up with, what we have been fed, kind of
like that's what our professor said to us. So you have to much more accept that you're in a
moving environment and that you cannot have this closure for the six months that your
development takes. So you have to actually, instead of having all these techniques and
notations to actually box your project you have to think about how do I communicate? How do
I keep track of the users? And for that we need to develop techniques and tools and concepts
because we don't, we have a lot of software product developers who are obviously successful
and they all do stuff that we don't teach at the universities. They do user communities; they
run user communities; they have conferences for their users and for their partners; they have,
so they have pilot users and work with them. So all these kind of things we don't teach. So we
should actually started teaching it, and we should started developing and abstracting concepts
and methods for that.
>>: So if software development keeps getting faster or deployment, your cadence for
deployment you would like to be able to deploy daily. That works for things like Snapshot,
which at this point I'm sure the first person that Snapshot took them all of a week to build and
then they get 4 billion dollars for doing that. [inaudible] I forget which one they were, but what
happens to the pieces of technology that are complex, that are hard to build that you can’t
build in a week like getting a Windows kernel right? That's taken obviously years, and even just
to try to build like let's say some new feature into it even in the open-source world where they
go faster is really kind of a challenge. I mean it's hard to do that. So if you have such a fast
cadence does that mean that you can only have a fast cadence for the simple stuff? And what
happens to the complex stuff if your market changes every month? Then you're not done yet.
>> Yvonne Dittrich: I don't have an answer. So that's a good question. I think that is one of,
course in a way when you add people to fasten in the project you also add overhead, so at a
certain point in time I think people doesn't help you. Actually open-source ending gives an
indication about how software engineering could scale because they manage to scale and they
manage to have a lot of developers doing some kind of coordinated things to one piece of
software, even if they have a parliament, so they have government structures both
organizational-wise and tool-wise. So there is some kind of possibility, but it means also if you
start from scratch with the developing something there will be somehow an initial investment.
And maybe we are lucky that we don't have to develop all operating systems from scratch, and
somehow for the devices that, the new devices we actually know how to develop operating
systems. So we kind of experience; we can take that experience and continue based on it. So
kind of I don't have an answer, but you might look into the open-source communities to see
how this can be done.
The other thing is that you will still, for some more complex software we will still have, really
fundamental changes will take time. As a new concept for operating systems that might take
time.
>>: All right. Thanks very much.
>> Yvonne Dittrich: Thank you.