Today I had to deal with a “mystery” that had been happening with a piece of software in production environment from time to time, but my guess is that nobody paid attention to it because it was not devastating enough to cause a “middle-level management alert”. Anyway, the error message was coming from an external (to our own) system, so my first move was to ask the corresponding team to take a look. Their instant reaction was as usual: it’s your fault, check your input, don’t bother us again. Since I only maintain this system -which has no documentation by the way- I mostly turned to that team to get a clue on which part of the input data could cause this exact error, so that I could step-by-step return to the root cause. The good thing about their helpful reaction was that I had to dig deeper into both systems’ “architecture” -which maybe is too random to be thought as architecture but anyway- and interfaces so that I would be able to find out what was going wrong. It must have took me at least x3 – x4 more time this way but sometimes “you do what you have to do” .  I found the error and corrected it but today’s “journey” through some of my corporation’s systems and subsystems source code was quite thrilling.

I know I may sound a little bitter but, believe me, it doesn’t have anything to do with either my co-workers’ attitude or their programming skills -mostly because the last couple of years I can say I got used to both the culture and the skills level. Also, I hope I’m not one of those guys that constantly underestimate others’ skills or knowledge. My main disappointment comes from the lack of insight and vision for our systems, the development processes and maintenance procedures we follow, and the technologies & platforms we use and -more importantly- the ones that we could employ to make ourselves more productive and our systems more reliable and cheaper to develop, deploy and maintain, but we don’t. My impression is that no-one seems to really care enough to re-engineer the prevalent inefficient mentality. On the contrary: every time their approach doesn’t come up to the results they expect (or promise…) or is not able to scale properly (either from a technical or from a managerial point of view) the try to just throw more resources (either human or computational) to bypass the problems. And even when they feel the need to embrace a more appropriate and evolved approach or technology they do it so carelessly and without the required background that they give the impression they do it just to be able to use a couple of buzzwords in their meetings. Just like they did with object orientation (which actually resulted in adding meatballs to the spaghetti)  and just like they are currently trying to do with SOA (which was “interpreted” by one of our managers as “code cloning, at the end of the day”…!).

Anyway, I believe this kind of “strategies” have to do with high-level management which usually has a bigger need to look good on spreadsheets than to innovate technologically -even though modern software engineering approaches when adopted properly can bring significant cost reductions and improve both the quality of the systems and the productivity of the whole department.

The bad thing about my job is that I have to deal with technologies and IT mentalities that date back to the 80′s.

The good thing about by job is that day by day I realize in practice how different features of the modern software engineering concepts I study as a PhD student would have a revolutionary impact on the efficiency in which we develop and maintain our systems. Also, I think it provides me with a better view on what’s important and what’s realistic/feasible in a “mediocre” business application development environment -which I guess is usually the case.

Plus, I gained a better understanding of terms like “heroic programming” and “heroic debugging“…

First of all last summer I graduated from an Electrical and Computer Engineering school (5-year program) where in the last couple of years I specialized in Computer Science and even more specifically in Software Engineering. I had the opportunity to conduct a research-oriented diploma thesis and my work was supervised by an inspirational professor and researcher, who is also my PhD advisor.

The PhD program of my school entails that you have to pass 6 courses in the first two years of studies. Taking into account that I work full time I thought that finishing with the courses early would allow me to focus more on my research the years to come. This is why, after discussing it with my advisor, I decided to enroll in all 6 courses (3 each semester) and hopefully end with this obligation early.

But sometimes what seems an “obligation” at first, my be quite interesting experience in the end. And this is what I believe that happened with most of the courses I chose.

The courses were the following:

1rst semester:

- Artificial Neural Networks and Machine Learning

- Research issues in Software Development

- Technology of Communication

2nd semester:

- Software Analysis and Re-engineering

- Database Technologies and the Web

- e-Commerce Networks and Applications

Each of the above courses gave me the opportunity to focus on different research subjects in Computer Science, in Software Engineering and in Web technologies. In each one of them -besides classroom work or other homework- I had to either survey a specific research topic or develop/experiment with technologies and frameworks and report my findings. Also, in most of the courses I also had to present my work in class, which was really helpful. Actually, comparing how nervous I was in the first presentation and how calm and relaxed I was in the last one, I would say that apart from any other knowledge these courses offered me, giving me the opportunity to prepare presentations and to stand in front of scientific crowds in order to defense my findings was quite useful for me. Although I have been a speaker quite a few times before, with way more people in the audience and in way more tense (or even hostile) environments, I have to say that scientific topics and audiences are more demanding and more exciting (at least from a speakers’ point of view) -because if you’re lucky enough you get to answer (or try to do so) quite interesting questions which may also lead to interesting conversations afterwards.

So, to sum up, this year I dedicated most of my time and energy on the courses I had to pass and only around 30% on my research -which is, only now, getting a more clear direction. Although during surveying topics that are not very close to my research interests I sometimes felt that I’m wasting my time and that I should focus more on my area, there were several occasions that knowledge that I got from these surveys proved to be quite useful in either understanding or even coming up with approaches on problems we try to solve in our main research orientation.

Provided that I find enough time, I will summarize my surveys in following posts. Also, several practical issues of the first year were not discussed in this summary and I intend to discuss them later on.

I started this blog in order to capture my thoughts, my actions, my lessons and the mistakes I make towards my goal.

An extra reason for having such a web log is the fact that I face additional difficulties and dilemmas, since I work as a full time software engineer in a quite big corporation. I believe that many of the situations I encounter are worth blogging.

My free time is limited but, hopefully, this blog will help me track and review (from time to time) the steps I make (forward or backward).

As I mentioned above, the main purpose of the blog is to capture and expose my “PhD adventure”. I don’t think my posts will be interesting enough to catch the attention of random visitors, but my hope is that I’ll get a chance to communicate with people that go through similar paths.

Feel free to comment on and/or criticize my points and -of course- correct my (mis)use of English!