Software and other human factors
Part of the title of this blog post is borrowed from the famous Jeff Atwood. One of the creators of Stack Overflow. His blog Coding Horror
has been an inspiration to me. You should check it out.
I never took the course Software Engineering
course seriously in my undergraduate studies. I knew enough to not fail and thought of most of it as Hot air
processes stuff. I was very, very far from the truth. All I knew was the Requirements, design, coding, testing and maintenance. There was an old way of doing it linearly and the new “cool” way of doing it iteratively.
My interest ignited when I took the Software Engineering for Big Data Applications
in my winter term in grad school. I love the way the prof taught it. (That’s how he likes to be called! Prof. Madhavji) Nazim Madhavji’s way of teaching is fantastic hands-off and a discover on your own type of deal. There is no course textbook but a course project where he acts as a challenging and stubborn client (It’s all for the good as most commercial software clients have complex problems which require nuanced solutions. ). The classes were a mixture of academic papers from experienced software engineers discussing the application of theory and how often (significantly less) they work. Many stories and experiences from Nazim’s history of working with various software types, companies that build them, and their attitude towards software engineering research made it even more Interesting. I ended up learning a lot about the domain, and the most critical lesson to quote Edward Berard Walking on water and developing software from a specification are easy if both are frozen. . TLDR; Most of the time, it’s deep waters and high tides.
Another factor about Software Engineering is that it’s often a team activity. Unlike some other scientific fields, you cant tuck yourself away in a room writing code or solving problems. There are clients, Programmers, managers, various known and unknown stakeholders, deadlines, legacy technologies, Modern technologies, limits on resources, millions of dollars involved and most complicated of all, the diverse crowd of people with disparate backgrounds. It’s a balancing act that one has to perform among these conditions and should come up with an excellent solution to the problem at hand.
Something like this interests me as it’s not monotonic and gets more interesting as you grow as an Engineer. I really have to thank Nazim for sparking my interest in this domain. I am looking forward to reading, learn and explore more in this field.
Footnotes :