Thought Flow

Technology and other things

Tag: developers

  • Becoming a data scientist

    Data vs. Spock (70/365)
    Data vs. Spock (70/365) by JD Hancock (CC-BY)

    It is is interesting how a job title carries certain connotations and how it can even be tailored to different situations. Sometimes I have called myself a Consultant, because this is what consultancies expect. Sometimes I have called myself a Developer, because that is what hiring companies expect. Sometimes I have called myself a Software Engineer, because it sounds good to Google and Amazon. All of the titles are technically correct (I hope), but create slightly different associations and expectations.

    In my current position at Receiptful, things are a bit different. I am now a Data Scientist. This is not a title I applied for or have ever used about myself. If someone called me a data scientist before I started at Receiptful, my response would be: “Well, I don’t feel like a data scientist. I’m a developer with knowledge of data mining.”

    This is the first time I have not made up my own title. It was handed to me and now I have to live up to it. The funny thing for me personally is that “data scientist” is actually a title I have aspired to have for a long time, but I just never felt that I was entitled to call myself a data scientist. Data science is such a hot topic right now, and I really do not want to seem fake.

    So for now, I will continue to build cool stuff and hopefully, the title becomes self-evident after a while. Time will tell :-)

  • Ubuntu — so ready for developer time

    In my previous post, I said that Ubuntu is not ready for primetime. I still think this is the case for most people. However, since writing the post I have acquired a Dell XPS 13 with Ubuntu 12.04 pre-installed (they call it a “developer edition“). Let me tell you, it is an absolute joy to work with and there have been no problems so far. Everything just works.

    Finally, I should note that I have been using Ubuntu extensively for development in recent years. I have just usually been running it in a virtual machine where there is no “weird” hardware present (such as optimus). My server that hosts this website is also running Ubuntu. So maybe it sounds a little harsh when I say it is not ready for primetime because it is definitely ready for developer time.

  • Why you should not use Microsoft Silverlight for your next web application

    You are running a Silverlight 4 application. You may experience incompatibilities as Moonlight does not have full support for this runtime yet.
    The above warning message sums up everything I dislike about proprietary web technologies. Silverlight is a fairly new Microsoft technology from 2007 and Moonlight is its Open Source and not up-to-date equivalent that I have to use because Microsoft does not provide Silverlight for Linux. Since most software only run on Windows anyway why is this so upsetting? Well, everything is different on the web.

    First, the premise for Rich Internet Applications (RIA) like Silverlight, Flash and even Java is ok: A website usually does not provide much “action” in itself so having an extra plugin running on the website with some access to the underlying system resources as well as built-in extra functionality will provide a better user experience. Microsoft writes on the Silverlight website:

    Silverlight is a powerful development platform for creating engaging, interactive user experiences for Web, desktop, and mobile applications when online or offline

    That sounds good and I do not necessarily disagree with the premise for RIAs but the question is: Why did we need another RIA platform that doesn’t really work? I don’t exactly know. However, it is understandable from Microsoft’s viewpoint, given their history of locking-in people to their platforms and the fact that they have legions of .NET developers that are probably very comfortable staying in their own environment when writing web applications. For them, Silverlight is probably bliss.

    But there are some problems, one of them being its availability. As of this writing, Silverlight is only supported in roughly 61% of all browsers, according to statowl, or roughly 69%, according to riastats. As the above warning message suggests, it does not work perfectly on (my version of) Linux, even with the newest Chrome browser and Ubuntu 11.04, the arguably best supported Linux version out there. Indeed, most of the Silverlight applications that I have looked at did not work very well, including an app that I was offered to work on1 and popular services such as Netflix which currently does not work with Moonlight.

    Again, the question arises: Why is this so bad? Isn’t this the same as always? No, it is a problem because the beauty of the web is its openness, and this openness is what Microsoft is challenging. The same applies to Flash. You may call Apple snobbish and manipulative if you like but Steve Jobs does have a point regarding Flash as a platform:

    Most Flash websites will need to be rewritten to support touch-based devices. If developers need to rewrite their Flash websites, why not use modern technologies like HTML5, CSS and JavaScript? … New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future …

    In my opinion, this would apply to Silverlight also. To be fair, Microsoft is embracing standards like html5 in Internet Explorer 9 but at the same time, they continue to push Silverlight forward. Some people think that this is not a problem since html5 and Silverlight are not direct competitors. But because of Microsoft’s power, Silverlight applications are shooting up everywhere which cuts off some users from using certain services of the Internet, something we have not seen on the same level with Flash. And this is a troubling development.

    There is only one way of avoiding that Silverlight will dominate the next decade of web applications as Flash did in the past: Stop developing applications for it. My choice should now be clear. But I fear that I am almost alone.

  • Guess-driven development

    A few days ago, I received a link to a blog post called some lesser-known truths about programming. Among other things, it states:

    Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.

    Patrick, my business partner, jokingly calls this Guess-Driven Development and I now take the liberty to publish the term in writing. I will admit that I have fallen for this type of development quite a few times. But now I have started to wonder: Where is the fine line between guessing and exploring?

    When faced with a strange bug or error in some system, we are taught to use e.g. a debugger and over time, we hopefully become more adept at solving bugs. But sometimes (many times) I have solved a problem by almost randomly trying out different solutions. So is this guessing or exploring? I don’t have the answer.

    Maybe I should have listened more carefully in Software Engineering class?

  • Passing the torch

    In the software industry, I believe there is often a somewhat strenuous relationship between developers and salespersons. Yet, there is often a perceived symbiotic relation between them. The developers develop and the salespersons sell. One couldn’t exist without the other.

    So far so good. Let’s assume (and hope) for a while that a salesperson is actually better at selling software than a developer. That’s good, right? The developers can focus on development and the salespersons can focus on selling. Everyone’s happy. Where does it go wrong then? When the salesperson also decides on new features.

    Features sell. Promises sell. The more a salesperson sell, the more successful he/she will look. After a salesperson has successfully sold a new feature, the torch is passed over to the unknowing developers who can do nothing but nod their heads and start implementing the requested features. After all, the features have already been sold.

    Now, most things are — fortunately — possible to do. But there are still at least two problems:

    1. Salespersons cannot give accurate time estimates because they do not know what they are talking about.
    2. Developers get frustrated because they do not really want to implement some salesperson’s idea and then the famous torch gets passed on to someone else.

    It does not have to be like this and I know that in many companies, developers actually have a say in what features are feasible to implement. But I have a feeling that as soon as a company grows and the distance widens between developers and salespersons, problems will arise. That’s why we do not necessarily want to grow — at all.

    Hmm, I actually wanted to write a blog post about how awful it is to be disturbed in one’s work due to supporters with frustrated customers on the phone. But there you have it. I added supporters to the rant in one sentence.

    I need to laugh more.