Re-inventing the Object

I have spent some years now working as a software architect. There were couple of rather large projects, in both Java and .NET, that I was working on.

Infrastructure vs real problems

The thing with software architecture is that it tries to set up some basic rules, and solve some primary problems, so that rest of the team can carry on implementing features. Large amount of these architecture problems, from my experience, fall into the category of infrastructure.

Now what do I mean by infrastructure problems? When you first start learning how to program, you are playing with objects, variables, and applying some logic to them in order to get the results that you want. It is the problem solving activity which brings lots of value, and also personal fun in the programming. Later, when you start working with real projects, it starts to look very different. Large part of the challenges you face are not direct problem solving, but rather configuration and setup. We are spending a lot of time to get the data where we want it.

Objects are outdated

Now why is that? Well, modern programming languages and tools are not addressing the infrastructure issues. You still need to think about your objects, which need to be serialized in order to be accessible by another remote system, and also need to be mapped in some sort of ORM in order to be persisted, and so on, and it is wasting time, which should be spent on solving real problems.

Imagine the time when the higher level languages started to replace assembly programming. In those days programmers started to get more productive when they used higher level language, because it abstracted away the complications of dealing with registers, stack and so on. Make no mistake, you still needed to be familiar with assembly in order to really understand what is going on below, but still using those high level tools made them more productive.

A new solution

I propose that we take things one more level up, which would abstract away our  infrastructure issues with data distribution and access, and leap into a new level of productivity. It requires that we forget about objects and services and databases the way we think about them today, and start looking at as infrastructure. Then, we can abstract it away and focus on problem solving, with a new kind of solution for our objects.

An emerging new approach which addresses these issues is the open-source IOG library, which recently published a first alpha release for the .NET platform. Give it a try, and let me know what you think!

Blind spot of software development methodologies

There is a trend of rise and fall of different software development methodologies. There is also a lot of discussion and excitement about which is better Agile or Waterfall or whatever, and what is Scrum really. My impression is that there is a trend of accepting processes and practices, with expectation that there will be always better results and fewer problems, which is not neccessary nor feasible.

Although I can see that some methodologies can have certain advantage over another when applied to a concrete software project + team + company, there is something missing. There are parts of software development which also can affect the success of a project or a team, or a company, but is not a methodology matter! I would like to think aloud about these simple things which somehow are underestimated, and are still very important:

Plain competence

You cannot have enough of this! Is it possible that you are oversteering our projects because your team is not competent enough? Just think about this: When was the last time anybody from your team picked up a technical book related to your project? Having a competent team will result in team members going for it, instead of looking for excuses.

Common sense team workflow

Does it make sense that whole team attends a meeting where most of the time couple of people have a discussion about how to implement something? Saying it is a scrum thing will not make it better, it is still a waste of time. I’m not saying that meetings are always bad, my point is that you should think about it if it works for your team. My suggestion is to let team decide on the workflow as much as possible, have them included. Also, having a process of “their own” can have benefits to team morale.

Every team is unique

My experience is that putting a group of people as a team will always produce results and processes which are unique to this team. If you force some sort of process onto them, sometimes you will get partial results, because team tends to work exactly the same as before, with additional overhead of being “compatible” with given process. Even if there is benefit, there is inertia to accept something “just because”. Team should have freedom to measure and accept practices which are working for them, and reject the ones which don’t.

As a conclusion I would ask a question: What other things in software development process do you think are important? What experiences from other teams can be applied to your team, and what certainly cannot because you are too different?

The trouble of finished software

I think that there is a very important question, and that is the question of what constitutes a finished software.

Well, that might seem easy. It should just work as specified.

Having a good specification is by all means helping to remedy this problem. Specification might be defined somewhere in a document up-front or agreed upon during the agile process. One trouble with relying only on specification is that natural language is not very precise, especailly compared to the programming language, therefore leaving room for interpretation. There is always room to write better documentation, but it will not make the problem dissapear. One of the possible paths is to look for formal specification methods, but the problem there is that not all stakeholders can interpret the formal pseudo-code or diagrams.

Assuming we have a decent specification, how could we tell if our software conforms this specification? Testing comes to mind, with all its variety of approaches, but also code inspection and analysis. Unit testing also has a mission to check if software conforms the specification, assuming that tests represent the specification accuratelly. Even with all these activities in place, we cannot have 100% conformance, because testing and unit testing always rely on some representative samples of behaviour. Maybe with good formal definitions we can have high conformance which is possible to check, but I haven’t used these tools myself.

Going back to our problem, it seems as the level of finished can be defined as combination of level of completeness of specifications, and level of conformance to the specification:

finished(software) = completeness(specification) * conformance(software, specification)

It is very important that all stakeholders in software projects understand that “finished” is a vague category, a matter of discussion. The term itself sounds as the final state, which is very different from reality. Maybe the term should be replaced with another term, such as “acceptable”, because it implies a level of acceptance. And level of acceptance is matter of agreement, which must be explicit between all parties.

To conclude, concept of finished software is too idealistic, and should be replaced with acceptable software.

Analysis of software developer’s competency – Choosing a right team member

In this post I shall try to explain an approach for estimating developer’s skills. The approach is still as a concept, which lacks some concrete decisions, but you can choose the thing which suits your case best.

There are number of methods for estimation of developers skills, my favourite being the developer competency matrix. This method is very good, and it prooved to be useful for general estimation of different skills, for example as a part of a general employment assesment.

But here it is relevant to estimate competency with relation to specific project, for example when choosing a right team members for a specific project, assuming we have a list of potential candidates to choose from. I would also like to automate this process, so the approach excludes the personal qualities for that reason – being not quantitative.

This is no easy task due to vast space of different skills one might have, so I shall restrict myself only to most common types of software development, which are web and app development for the most common platforms.

Additionally, most developers I work with are also involved in organizational activities, such as team management, customer relations, communication… I shall try to isolate these qualities out of this analysis and focus on pure technical skills.

We shall try to represent this software developer skill space with different dimensions:

  • programming language
  • tools and libraries
  • platform
  • application type
  • experience (lenght)
  • role (depth)

These dimensions are basically factors which are taken into account for the competency analysis. There may be other relevant dimensions added.

Programming language dimension is pretty obvious, it is a distinct list of items such as c, c++, java…

Tools and libraries dimension represents various IDE tools, compilers, editors, frameworks, and libraries which are used when developing software.

Platform dimension is representing the environment in which application is deployed, and encapsulates both hardware and software environment. It is also a distinct list of items, such as windows, linux, iphone, desktop, silverlight, flash…

Application type dimension represents the domain in which the software is being used, and it is also a distinct list of items such as “information system”, “online sales”, “banking”, “medical device”, “web portal”, “social network”…

Experience dimension represents simply the length of experience for particular development which has already happened in the past.

Role dimension represents level of the development activity and may contain items such as “apprentice developer”, “medior developer”, “senior developer”, “software architect”, “platform architect”…

With these dimensions one should be able to define a metrics system for measurement of general competencies, or a measurement system for a specific project.

Simplest thing to do is to represent the metrics as a linear combination of the dimensions, but there may be other useful methods as well.

For a specific project different weights are given to any value in each dimension. This way, basically, we define what are we looking for in a candidate. If we accept only Java developer for a position, we would give other programming languages a zero weight. If we need a candidate to be a senior, but also accept medior developer, we assign appropriate weights to these values.

Our candidates need to fill their values for every relevant dimension, or we extract that from the CV or an interview, giving us values we can work with.

Then, for each candidate we calculate the metrics, and choose the one with the highest score!

It would be interesting to create a web app which would allow online calculation of the competency based on a given criterion.

Not to be forgotten, there are other – more human factors which need to be considered. I shall reflect on that in a separate post.

A quick replay of Sokoban

Looking back at my student years, one of the personal projects I’m most fond of is the “Gurko” game. In fact it is an exact clone of famous Sokoban game, with some cool additions, such as mouse play, navigation points and path recording, for those repetitive levels. Unlimited undo of course…

Game screen

This project served as a learning challenge for Delphi 5 and GDI environment back in year 2000. Having more than 350 levels, taken from a version of WinSoko, it is a lengthy playing experience. If you are still up to the challenge download a free copy here. It should run on all recent Windows OS versions. To start the game, simply unpack the archive and start the gurko_en.exe.

Back in the microcomputer era

Even before PCs roamed the earth, there were a different kind of computers. Compared to today’s devices, they were big and clunky. Even the simple operations were difficult to perform, and complete absence of OS meant that you could do two things, either play with and use existing programs, or write your own. Popular magazines at the time were full of real programming tips and tricks. I remember that there was a contest where the task was to exchange values of two variables with least amount of processor cycles in Z80 assembly. OOP was nowhere in sight, and words like GOTO, POKE and REGISTER were part of usual articles in the magazines. Oh, yes, and there was no internet, so getting your hands on some new cool app meant that mostly you got to type in the code, which was sometimes given in the magazine in printed format as a set of machine code instructions. If your computer had a way to save the data, yay!, if not, that meant you had to type all over again if you wanted to play tomorrow.

However, it was a time of creativity, and I started mine with Sharp MZ 700 computer. Equipped with mere 10 games it started to get boring after a while. Luckily there was a kid friendly book on programming in BASIC which came with the computer. Working through the book, after a while I realized it was a way to make games, being at very young age of 12, it was the first motivation to mess with the computer in the first place.

After a while there were real mini games starting to emerge from the code, first and foremost, the TETRIS clone off course. Unfortunately, I was unable to salvage the original data from the data tapes for that game, but I remember it having around 500 lines of code, which was huge at that time!

But there were others, starting from roughly 1992 until 1997 I created about 20 games, mostly remakes from popular games at that time. But only recently, by using a tape conversion application, I managed to port some of my early creations from old tapes to modern digital file format, which is readable by MZ 700 emulator, and brought some old code back to life.

I wish to give credit and greets to guys from for their work on emulator and tape conversion tools. And yes, here are some retro in-game images taken from the emulator, enjoy!