Software Público Brasileiro

\section{Lessons Learned}
\label{sec:lessons}

\textbf{How to involve students real-world projects, interacting with
real customers.}
%
Our team was mainly composed of software engineering undergraduate
student, who had the opportunity to interact with senior developers and
designers inside the team, as well as with the team of technicians and
managers from the Brazilian Government, and the management team from
UnB.
%
They interacted with professionals that had diverse expertises, and were
able to participate in all levels of the software development process.
This contributed to a great learning opportunity, and for a majority of
them this was their first professional experience.

\textbf{The participation of experienced professionals is crucial to
success of the project.}
One important factor for the students was the composition of the teams
with the participation of experienced professionals.
%
On the technical side, the senior developers and designers would handle
the more difficult technical decisions, creating a work environment
where the students could develop their skills in a didactic way without
pressure.
%
On the management side, the active participation of professors -- who
are, in the end, the ones responsible for the project -- is crucial to
make sure student participation is conducted in a healthy way, and is an
instance of leading by example.

\textbf{A balanced relationship between academia and industry.}
The experience of the SPB project led UnB to develop a work style which
proved to be appropriate for an educational environment that brings
academia and industry together.
%
The highest priority from the university's point of view is the
students.  Considering this, the activities of the project were never
prioritized to the detriment of classes and other pedagogical
activities. In summary, we had students working at different times, part
time, remotely or locally, always respecting their individual
conditions, but doing the work in a collective, collaborative and open
way.
%
And even under a potentially adverse environment, the project delivered
the desired solution with success.
%
At the end of the project, we noted that the skills developed by the
students were at the state of art of the software engineering practice.
After the project ended, we had team members successfully embracing
opportunities in public, private, national and international
organizations, in addition to those students that went into
entrepreneurship and opened their own companies.

\textbf{Managing different organizational cultures.}
In the beginning of the project, the Brazilian Government stakeholders
had certain expectations about the development of project that, let's
say, didn't exactly match our work based on agile and FOSS practices.
%
We had to develop strategies that would support different these
organizational cultures. As reported in Section \ref{sec:process}, the
MP is organized in a functional hierarchical organizational structure,
typically, a  traditional development paradigm. Therefore, we had to
create a translation process between our team and the MP managers who
managed the project on their side assuming a traditional, waterfall
process.

\textbf{Manage higher-level and lower-level goals separately.}
During the initial phase of the project the MP team would often bring
strategic discussions to technical/operational meetings, where we were
supposed to discuss practical, technical decisions.
%
This produced a highly complex communication and management environment,
overloading the professors because they were supposed to be responsible
for maintaining the strategic alignment of the MP synchronized with
implementation plans of the development team, specially in light of the
aforementioned culture mismatch. Mixing both concerns in the same
discussions caused confusion on both sides.
%
Towards the middle and end of the project we were able to keep those
concerns separated, what eased the work of everyone involved.

\textbf{Living with ill-advised political decisions.}
At the initial phases of the project, by political and personal
motivation, the main stakeholders from the Brazilian government imposed
the use of Colab to guide the development of the new SPB platform.  Our
team was totally against the idea because we already knew that Colab was
a very experimental project and its adoption could dramatically increase
the project complexity.  Even though we provided technical reasons to
not utilize Colab, MP was adamant and we had to manage this problem. As
explained in section \ref{sec:architecture} we did massive changes to
it, and at the end of the project we completely rewrote Colab and made
it stable. It is important to notice that the MP compelled us to accept
a technical issue based only on political interests, without considering
all the resources that would be spent due to that decision. At the end
of the project, we verified that Colab indeed consumed a vast amount of
the budget and increased the project complexity. In the end of the
project and after our analysis on the decision made by the MP, we
understand that MP's managers are capable of ignoring technical reasons
in favor to a political decision.

\textbf{Consider sustainability from the beginning.}
In the process of deploying the SPB platform in the MP structure, we had
to interact with the MP technicians. We did several workshops, training
and a meticulous documentation describing all the required procedures to
update the platform, however, we realized that the MP technicians
constantly avoid the responsibility. After noticing the aforementioned
situation, we organized a specific DevOps that completely automated all
the deployment procedure. We simplified all the platform deployment to a
few steps: (1) initial configurations (just ssh configuration) and (2)
the execution of simple commands to completely update the platform. By
the end of the project, we observed that the MP technicians invariably
still depended on our support to update the platform even with all the
automation provided by us. We were sadly left with a feeling of
uncertainty about the future of the platform after the project ended. In
hindsight, we realize that the MP dedicated systems analysts and
managers to the project, but not operations technicians. The later
should have been more involved with the process so they could at least
comfortable with managing the platform infrastructure.