FEATURE : SOFTWARE DEVELOPMENT
While one might assume that presenting a robust technical solution would result in acceptance in the building process , it is not that straightforward and there is a need to convince others of the solution ’ s validity , says Gabriel Eisenberg at Synthesis Software Technologies .
While one might assume that presenting a robust technical solution would result in easy acceptance and progression in the building process , it is not that straightforward . There is a continual need to convince others of the solution ’ s validity , align perspectives , address miscommunication openly , build both relationships and trust over time , and collaborate closely with the client and team members .
So , is the solution to avoid people entirely ? While tempting for the stereotypical introverted engineer , it is likely impractical and would lead to isolation . Moreover , the most intriguing and challenging technical problems and solutions often emerge from collaboration .
As overwhelming as technology can be , it is generally predictable . Often , the challenges developers face boil down to misconfigured code , that can be adjusted over time , humorously referred to as PEBCAK : Problem Exists Between Keyboard and Chair . Alternatively , software providers can release patches or introduce new features .
On the other hand , people are far less simple , even in professional environments . People can have good days and bad days , exhibiting varying behaviours in both cases . They also have numerous underlying motivations , individual biases , and different knowledge foundations . These factors result in inevitable gaps that can be challenging to bridge . To do so requires clear communication , understanding , adjustments of one ’ s own behaviours and paying attention to the other person .
In my experience , I found it rather surprising that people encompassed about 50 % of the challenges and technology accounted for the remaining 50 %. Conversely , as a Sales Engineer , I found that 90 % of my problems came down to people , leaving only 10 % as technical issues . Even as a developer , the human element cannot be evaded , with an estimated 20 – 30 % of challenges being people related .
As a consultant , one will always be interacting with a client , both at the stakeholder level and at the user level . One needs to be considerate of who one is speaking to . From the broader business context to the nuanced dynamics of interpersonal communication . Each facet plays a role in shaping successful outcomes for projects .
I have been reading Fundamentals of Data Engineering by Joe Reis and Matt Housley . While the extract below is framed for data engineers , I believe that it generalises for technologists working across industries : Without a framework for managing data , data engineers are simply technicians operating in a vacuum . Data engineers need a broader perspective of data ’ s utility across the organisation , from the source systems to the C-suite , and everywhere in between .
Upon reading these two sentences , what struck me was how this related to my experience working in a platform team responsible for the development of an enterprise scale data lake . As a relatively small but competent team , we were overwhelmed with the demands of the many teams and stakeholders who wanted their data to be on the data lake or wanted to consume from it .
In trying to make the data available and conform to consistent formats despite the inevitable , seemingly
Are you planning for the human factor in software development ?
34 INTELLIGENTCIO AFRICA www . intelligentcio . com