why not? (reprised)

November 27, 2015

Many thanks to those that commented directly on my blog or sent me an e-mail. Here’s an amalgamation of the others’ and my thoughts. My apologies if it took some time as it takes me awhile to process things carefully.

I think a portfolio approach to theses is the key: like in all things balance is essential. There are political and commercial realities that we need to be conscious of. A realistic mix needs to be identified and articulated per institution. There are several parameters or axes that can be used: for example, the funding model. Some maybe completely closed or proprietary for the exclusive benefit of and sponsored by a single institution. Others may be free and open-sourced for anyone to use as long as enhancements are shared. I suspect that most will be somewhere in the middle: most will be openly available but certain parts will be restricted preserving explicit trade secrets against being a good corporate citizen. I don’t espouse a single model but I think the last one is more workable.

Organisation size is a bit more problematic. We can be tempted by “largish” ones as these are often viewed as more prestigious and worthwhile for the effort. The rub is in facilitating this for “smaller” organisations, Maybe an exchange of some sort or crowdfunding (the “Piso Para Sa Pasig” comes to mind) can be used – your guess is as good as mine.

When it comes to scheduling, I think people need to be more courageous (it’s definitely not easy) as Brooks and McConnell espoused. We are often “scared” of what the market, client or boss will think: we want to please them even if we need to be untruthful. As previously developed, I do agree that we need to come up with three schedules ( sure it’s more work upfront but it can save a lot of headaches later on): one that’s optimistic and ideal, another that’s pessimistic where what can go wrong does, and finally a realistic one. It’s about identifying likely potential risks and planning for a doable mitigation strategy. Efforts like COCOMO and COCOMO2 should be applauded but an “easy” to access and update coding-cost model that includes “newer” technologies would prove handy. A database of time and effort to develop a particular functionality in a given tool. Maybe someone’s already done this but it should be readily available to those that need it. Here’s where institutions of higher learning can come in: they are not only in a position to contribute to this service but have the power to keep the contents “current”. I know programmer skill levels are contentious – depending on which study you believe it’s anywhere from a factor of four to ten where they differ. My own experiences and common sense dictates that this variability exists. These estimates are merely a baseline and one needs to adjust accordingly. The point is there is an “objective” measure or a basis for the plusses and minuses to the proposed schedule – this may not be perfect but this is why capability maturity models and personal mastery can be useful.

There is still a place for basic or “pure” research. I don’t think academic rigor or standards need to be sacrificed. Realistically, what percentage of theses, eventually, give rise to advancements? I’m not saying work must be only practically-inclined – I subscribe to the adage that there is nothing as practicable as a good theory. It is binary thinking (1s or 0s, black or white, either-or, etc.) that can be pernicious – the quantum computer has a state where it’s on and off at the same time. What do they say: genius is having two diametrically opposed thoughts at the same time. What I’m saying is that theses can both advance the field and be immediately useful – students can meet the expectations set by teachers. A positive culture must be put in place so that social proof can be leveraged.    Not surprisingly, I’m an advocate of Pasteur’s Quadrant (see image below from http://curryja.files.wordpress.com/2013/05/pasteur.jpg using a Google image search).


Don’t get me wrong: achieving this balance is extremely difficult but a mix we should strive for nonetheless.

Exposure to industry and project management techniques has shaped my thinking on scheduling impacts. Scoping needs to be realistic. Costs, Schedules and Quality are all points in a triangle that determine what’s ultimately delivered – prioritising one means compromises to the other two. Most projects are beset by cost overruns and time delays partly because an inaccurate schedule was proposed to start with. If time is a real constraint then perhaps the Design To Schedule methodology is an appropriate approach.

That’s why I prefer mobile apps, they are “reasonably” priced and there appears to be better cohesion unlike the software packages that are often plagued by functional overload – I do not blame vendors from wanting to keep selling a “newer” version as “new and improved” features are meant to justify each upgrade. Here’s where a cloud-based or a subscription scheme can be beneficial. That said, we need to be aware that “fast” internet connections and funds are not always givens – we must be conscious of developing economies that also rely on them.

I’ve always believed that a multidisciplinary approach is often required to solve major problems – so much so that I previously was not keen on specialisation. I’ve since changed my mind and have a symphony approach to things: where we all play different parts; have distinctive functions or roles; and diverse viewpoints or perspectives. Stove-pipe divisions can be quite limiting and bring group think to isolated silos – like the story of the elephant where factions are only cognisant of a part of the beast and not the whole animal. I think this is understandable for an “established” organisation but I fell this type of vertical division is somewhat old-hat; while a purely horizontal arrangement can be quite chaotic: I think the “sweet-spot” is somewhere in between and institutions should be organised instead according to focus or research areas making cross-disciplinary membership possible and even encouraged.  If I learned anything from computing it’s that most problems are divergent and there’s more than one way to skin a cat. Consistent with Software Engineering and Project Management principles, it’s folly to assume all tasks are perfectly divisible and have acceptable communication overheads. There’s some merit to considering what “others” or prototypical end-users have to say – although one needs to be careful with opinions as they are likened to a particular body part: wheat and chaff; signal and noise; and all that. There can be collaboration with other disciplines to help maximise the robustness of ideas lest we view all problems as nails.

None of what I said is new nor original: what we need is to facilitate inclusion into standard practice. I know that most of these require a blog post of there own but this is partly a summary and response to all the comments I received (thanks again). It needs to integrated and not tacked on – usability and professional ethics are good examples. Hell, I’m guilty of violating these tenets at times but as these practices are more widely adopted or deeply ingrained it becomes less likely that we encounter such issues. It needs to go beyond an Ad Hominen argument (although consistency can be a real bugbear) but even if there’s a fault with me, it doesn’t make what I’m saying any less true. This does not pretend to be a complete argument but merely a jumping point for more discussions. I’m not that smart but smart enough to know that others are better placed to take an idea and run with it or have a completely different (or better) one.

why not?

November 4, 2015

I think some theses done in the Philippines can have a more concrete impact on society in general and specifically identified communities in particular. Sure there are some that consider this but, in my mind, not nearly enough. I came from a college (or as we refer to it in Australia, division) where most works were on the shelf gathering dust. We tended to focus on the novelty factor (sure there needs to be a genuine contribution to the field) but it is often at the expense of a direct impact. Sure, part of it is changing the mindsets of students but, more importantly, it is having panelists and advisers think differently.

Maybe it is because most have a software component (sure sometimes it is developed primarily to drive the hardware but arguably it may have broader applications.) Funny that we teach reuse but we rarely build on past projects (maybe it is for the same reason that people start a new foundation instead of contributing to an existing one – in my mind it partly boils down to an issue of control and ownership). I espouse the use of open-source but even I note the realities of forking. Conceptualising the project we often concentrate on the ‘What’ and the ‘How’; often times forgetting the more important question: ‘Why’.

Some people are familiar with SaaS (Software as a Service) – emphasis on the last word. What I am proposing is an explicit broadening of this paradigm: SaaSE ( Software as a Service for Empowerment). According to current definitions, it is not exactly an extension but a reappropriation if you will. Outright intention is the difference. Sure, I am aware of the caveats: the road to hell and all; but this should not be a reason not to even try.

There is no reason that this should be limited to colleges of computing (although the applications are much more obvious). Fields such as engineering or science are also important but other areas such as economics and psychology are also useful. This should not be only limited to my explicit examples but as long as they can utilised for the common good like government, small business and NGOs to name a few, it is worth looking at.

This is by no means refined but some thought was put into it. They can’t be all gems and some of them may be utter rubbish – I do not often agree with Bill Gates but I’m also of the mind that success is a poor teacher. I think a blog is a suitable medium to share an opinion, to get a conversation started, to improve ideas and to garner feedback – hell, it may even lead others to better or different notions. The point is to eventually arrive at something that can be practically implemented.