Friday, August 01, 2008

Communication, interpretation and software engineering

A majority of problems in software engineering are due to inefficient social activities, well... beyond poor estimation, poor assessment and poor verification of course. :)

Here's a very nice website I found:

http://www.radio-subterranean.com/atelier/creative_whack_pack/pack.html

It's focused on creativity, but can be applied to innovation and some of those issues can be applied to general software engineering that's simply the development of applications.

There are still quite a lot of apps out there that have not been designed properly. They start out, but from that point are already dead in the water. It's simply no use to extend it further. It may work when it's done, but every effort spent on it simply isn't worth it. "Design-dead", it's called. This can be prevented if you look for sounding boards and more experienced peers. Don't be proud, let others contribute and seek some help in what you're doing.

The other thing are assumptions or assumptions from business that turn into dreamed up requirements but eventually appear to be problems. Especially for security this could be the case.

The latter problem is mostly the lack of root analysis. Rather than directly assimilating what a person wants, it's about asking the question why something is wanted and what the root problem is. Many, many times, people come to you directly with a request to do something which they consider the resolution to their problem. They're not telling you the problem they're having. Keep on asking, identify why something is wanted and maybe it's possible to come up with a much easier alternative.

Lack of definition is another. It's difficult for some people to understand that others are not experts in the same domain. Spend a bit more time to explain your own process and activities, then see if you can develop a correct cross-over between the two domains of expertise for an optimal result.

Well, and further... It's mostly about continuous communication and verification. Going off for half a year and then coming back with an end result is bound to give a lot of deviations from ideas. Maybe the ideas were wrong in the first place, maybe the interpretation. It doesn't matter at that point.

2 comments:

MGoel said...

Nice one. Came across your blog through common interest in innovation.

With regards to -- "assimilating what a person wants" -- i would say, in our world it's more about providing what people 'want' and not what people 'need'. That is where the management and tech views differ :)

Gerard Toonstra said...

It depends... It can go both ways. Many techs don't ask the right questions. But then again, some managers just want to tick off another success quickly and do exactly what is stated.

It may also be the economical model under which people deliver requirements. If asking for something also hurts them a little bit, it's easier to get it right.

Software engineering really isn't too far from economics. Supply/Demand is there, inefficiencies, market externalities and micro and macro forces that influence the bigger picture. Steering a project sometimes feels like working for the government. :)