by Bozho | Aug 13, 2015 | Aggregated, Opinions
Two months ago I took the job of adviser to the cabinet of the deputy prime minister of my country (the Republic of Bulgaria, an EU member). And I’d like to share my perspective of a technical person, as well as some of my day-to-day activities which might be of interest. How does a software engineer get to such a position in the first place? Some people from NGO that I used to be part of (including myself) communicated with the interim government our open source campaign and also built the OpenData portal of Bulgaria (based on CKAN). We continued the communication with the newly elected government and helped with opendata-related stuff, so several months later we got a proposal for a part-time advisory position. And I took it, reducing my software engineer job to four hours. I don’t have to mention that hiring a 27-year old software engineer isn’t something a typical government would do, so that’s progress already. What do I see? Slow waterfall processes, low-quality software, abandonware. Millions spent on hardware and software licenses which are then underutilized (to say the least). I knew that before, hence the push for open source and more agile processes. Basically, the common perception of the regular citizen is that millions have been spent on the so called “e-government” and there is nothing coming out of it. And that’s mostly correct. To be honest, I cannot yet tell why exactly. Is it the processes, is it the lack of technical expertise on the side of the civil service, is it the businesses’ inability to provide quality software, or is it...
by Bozho | Jul 25, 2015 | Aggregated, Opinions
Governments order software for their allegedly very specific needs. And the EU government (The European Commission) orders “visionary” software that will supposedly one day be used by many member states that will be able to communicate with each other. Unfortunately, a lot of that software is abandonware. It gets built, the large public doesn’t see the results, and it dies. A while a go I listed a couple of abandoned projects of the EC. Some of them, I guess, are really research projects and their results may be important for further development. But I couldn’t find the results. All there is are expired domains and possibly lengthy documents. But 100-page documents about software are not software. I haven’t seen any piece of code whatsoever. The only repo that I found is that of OntoGov, but all there is there are zip files with “bin” in their name. Even though unused, the software maybe isn’t lost (although the agency behind some of the projects doesn’t exist anymore), and may be utilized by new projects or even businesses. But it’s just not accessible to the general public. It’s probably hidden in a desk, in a dark basement, with a leopard warning on the door (as in the Hithchiker’s Guide to the Galaxy). But the problem is not only on EU level. It is on national level as well. Since June I’m an adviser to the deputy prime minister of Bulgaria (which I’ll write about another time), and from the inside it’s apparent that software has been built over the years and then forgotten. I’m pretty sure this is true in most...
by Bozho | May 3, 2015 | Aggregated, Opinions
I just watched Citizen Four, and that made me think again about mass surveillance. And it’s complicated. I would like to leave aside the US foreign policy (where I agree with Chomsky’s criticism), and whether “terrorist attacks” would have been an issue if the US government didn’t do all the bullshit it does across the world. Let’s assume there is always someone out there trying, for no rational reason, to blow up a bus or a train. In the US, Europe, or anywhere. And with the internet, it becomes easier for that person to find both motivation and means to do so. From that point of view it seems entirely justified to look for those people day and night in attempt to prevent them from killing innocent people. Whether the effort to prevent a thousand deaths by terrorists is comparable to the efforts to prevent the deaths of millions due to car crashes, obesity-related diseases, malpractice, police brutality, poor living conditions and more, is a non-technical question that I’m not qualified to answer – there’s social psychology involved. And regardless of whether PRISM has helped so far in preventing attacks it may do so in the future. Privacy, on the other hand, is fundamental and we must not be monitored by a “benign government”, regardless of the professed cause. And I genuinely believe that none of the officials involved in PRISM, envision or aim at any Orwellian dystopia, but that doesn’t mean their actions can’t lead to one. Creating the means to implement a surveillance state is just one step away from having one, regardless of the intentions that...
by Bozho | Apr 14, 2015 | Aggregated, Developer tips, Opinions
Accidental complexity, in a broader sense, is the complexity that developers add to their code and that is not necessary for the code to work. That may include overengineering, overuse of design patterns, poor choice of tools, frameworks and paradigms, writing snippets of code in a hard to read way. For example, if you can do a project with a simple layered architecture, doing it with microservices (and having to decide on granularity, coordinate them, etc.) or message-driven architecture (with setting up the broker and its queues’ all sorts of configurations) increases the complexity of the software unnecessarily, and is therefore accidental complexity. If you want to parse XML and covert it to objects, using SAX adds a lot of accidental complexity, compared to xmo-to-object mapper (e..g JAXB), where you just add a few annotations (hopefully). If your logic can be expressed with a few lambda expressions, but instead you do several nested for-loops with if clauses inside, then that’s accidental complexity. For me at least, accidental complexity is about making it hard to read, maintain and deploy with no good reason, apart from not knowing better. Essential complexity on the other hand comes from the world you are trying to model with your software. It’s about the inevitable edge cases you have to handle if you want your software to be fit for actual use. Essential complexity can and does make your code harder to read and maintain. It makes it look like “legacy” code, but as Spolsky points out, that’s the way of things, and that’s the way it should be. Unexpected API calls, classes that exist...
by Bozho | Mar 23, 2015 | Aggregated, Developer tips, Opinions
A couple of weeks ago I asked the question “Why non-blocking?”. And I didn’t reach a definitive answer, although it seemed that writing non-blocking code is not the better option – it’s not supposed to be faster or have higher throughput, even though conventional wisdom says it should. So, leaving behind the theoretical questions, I decided to do a benchmark. The code is quite simple – it reads a 46kb file into memory and then writes it to the response. That’s the simplest scenario that’s still close the the regular usecase of a web application – reading stuff from the database, performing some logic on them, and then writing a view to the client (it’s disk I/O vs network I/O in case the database is on another server, but let’s disregard that for now) There are 5 distinct scenarios: Servlet using BIO connector, Servlet using NIO connector, Node.js, Node.js using sync file reading and Spray (a scala non-blocking web framework). Gatling was used to perform the tests, and was run on a t2.small AWS instance; the application code was run on a separate m3.large instance. The code used in the benchmark as well as the full results are available on GitHub. (Note: please let me know if you spot something really wrong with the benchmark that skews the results) What do the results tell us? That it doesn’t matter whether it’s blocking or non-blocking. Differences in response time and requests/sec (as well as the other factors) are negligible. Spray appears to be slightly better when the load is not so high, whereas BIO happens to have more errors on...
by Bozho | Mar 13, 2015 | Aggregated, Opinions
The other day I read this piece by David Byttow on “How to land an engineering job”. And I don’t fully agree with his assertions. I do agree, of course, that one must always be writing code. Not writing code is the worst that can happen to a software engineer. But some details are where our opinions diverge. I don’t agree that you should know the complexities of famous algorithms and data structures by heart, and I do not agree that you should be able to implement them from scratch. He gives no justification for this advise, and just says “do so”. And don’t get me wrong – you should know what computational complexity is, and what algorithms there are for traversing graphs and trees. But implementing them yourself? What for? I have implemented sorting algorithms, tree structures and the likes a couple of times, just for the sake of it. 2 years later I can’t do it again without checking an example or a description. Why? Because you never need those things in your day-to-day programming. And why would you know the complexity of a graph search algorithms if you can look it up in 30 seconds? The other thing I don’t agree with is solving TopCoder-like problems. Yes, they probably help you improve your algorithm writing skills, but spending time on that, rather than writing actual code (e.g. as side-projects) to me is a bit of waste. Not something you should not do, but something that you don’t have to. If you like solving those types of problems – by all means, do it. But don’t insist...
Recent Comments