The quality of software - part four

In today's installment we're going to look at the quality of code from a broader perspective taking into account all the previous installments. I'll try to outline the difference between a good project vs a bad one, even though they both make money.

What is software quality

There is and always have been a huge gap between the end product and the code. That gap has been introduced some ages ago with tapes and cards. They didn't make any sense whatsoever to the end user as much as the code today makes no sense whatsoever to the user of your next brilliant application. Let's face it: programming is an art not everyone can do and even less people can understand (even if they are in fact doing it). So what makes up for a quality product?

There are 2 sides of the story: one is the "make it to the market ASAP" side which tends to solve the problem of competing with others. Depending on the size of the project it might seem like it is a good idea to rush developers into doing the least that'll actually work or to push in some features that'll make the customers so much happier.

The other side of it is that software is created by human beings and that in turn reveals the weakest link in the process of creation. Even though we can be extremely creative in our brilliant ideas we tend to make mistakes, tons of them. The faster you write code the less careful you are and the more bugs sneak in into the final creation...

Sure there are people that get it right the first time, always, but there's so few of them you could put them into the "exception" group for a rule that programming is a very error-prone activity.

So quality in the broader sense is something that is good for both the end user of our software as well as the agility to fix any bugs or introduce new features into the project.

I can fix any bug in the projects I wrote - and do it FAST!

That's a common misunderstanding that one can find bugs within software product they wrote. It is so because we, humans, don't stay the same for the duration of our lives. We tend to learn new things even if we don't admit it to ourselves. Let me tell you that looking at the code that I created 10 years ago scares the hell out of me! And I'm not the only one...

So even though we'd like to think that if we'd be the only ones creating the software we will at some point face the danger that our old idea was plain wrong. Due to the changes that happened to our lives we tend to think differently and curse that brain-dead monkey that wrote this stuff some years ago.

Uncle Bob says: Why did you write it?!

One should always try to be at ones best when writing code. Period. There's no excuse for writing unsustainable code - be it for private use or for the company you work in. There's no excuse to write code that will make you ask WTF every 5 moments. That'll make your life and the life of your fellow developers a living hell. And the worst part of it that it is not only you, the programmer, that will suffer from it - it's everyone in the chain starting with the guy that wrote it and ending with the programmer's worst enemy - the end user... How come? Well first of all you will curse the day you entered the project, then your architect will throw thunders at you for writing that piece of crap, then your manager will tell you that you need to go faster and cut corners and at the end of all this there is the customer that will probably go ahead and buy another solution that will not break as often as the piece of crap you and I created.

My old boss when asked about what is software quality explained it more/less like this:

The quality itself is not a goal for itself. But at the same time it is vital in order to sustain the company and the products it delivers

What it says is there's no one or the other. The world is not gray in this regard. If you make a loan in the code you'll have to pay it back in order to go further...

Summary

The summary of the whole series is quite simple: do TDD, do continuous integration, do pair programming, do code reviews, do make the querulous customer happy! They deserve it. You deserve it. You deserve to do the right thing. And if you can't do that then quit now and never look at software development again.

Grails and Ratpack

Today I've found out about the Ratpack plugin. Being a huge Sinatra fan I was quite fond of the Ratpack framework to begin with and naturally I was amazed to see it incorporated into Grails as a plugin. And it works!

Let me walk you through a very simple example of using Ratpack inside Grails.

We start by enabling the Ratpack plugin in our application. I called mine app "example" so all the URLs will be prefixed with "/example". To include the plugin you need to add it to grails-app/conf/BuildConfig.groovy like this:

With that in place we'll create a domain class to have some data to display. I'll go with the simplest possible class that represents a person grails-app/domain/Person.groovy:

Simple enough, right? Let's go an make some use of it in a Ratpack file. Create a folder grails-app/ratpack and inside of it a file called PersonRatpack.groovy:

As you can see here all we're doing is responding to the GET method on some root URL. Ratpack uses SimpleTemplateEngine from Groovy. We have to tell it where to look for templates Config.groovy:

So let's create one to display the people from database grails-app/ratpack/templates/list.html:

Simple enough, right? It almost looks like a mix of ERB and expression language from JSP. I think you'd have to ask the authors of SimpleTemplateEngine if those similarities have been made on purpose of if this syntax just seemed to be the only one that made sense...

Anyways, with all that in place we can add some people to the database in our grails-app/conf/BootStrap.groovy file like this:

And that's it! start the application, navigate to http://localhost:8080/example/ratpack and you should see the list of two people on the screen.

Needless to say you can accomplish the exact same thing using a controller and a view. The idea here however is to show you that there is life beyond the standard artifacts and that the beauty lies in diversity!

Hope this will help someone get started with this awesome piece of code!

Intermission

Today's protest against SOPA and PIPA acts have had a tremendous impact on Internet traffic around the globe. Millions of people have been made aware of the irresponsible propositions of attack on freedom in the Network. You can't name it any other way than censorship which is the public enemy number one by any definition.

I support Wikipedia, WordPress and all the others in their campaign against SOPA and PIPA!

God help us all when the time comes to kill the last free medium on the planet.

You don't get to drive - part three

In the recent installments we've looked at software development as a discipline that has its own way of working. Its history, however brief, didn't leave any room for being mistaken with anything else. It is the single, most dynamic part of our modern society. But how do people handle it?

If you're young, in Poland it'd be under 18 years old, you don't technically get to drive a car without adult supervision. That's pure theory nowadays but at least that's how it should be. Being young and funky gets lots of stupid ideas into your head like driving over 100km/h in town chasing a friend without knowing the road ahead. Been there, done that. It doesn't mean I was in my right mind when I did it.

There are places where being wild is good. Certainly things where life is at stake are not the kind of ones where you'd expect one to go all in without training but that's what is actually happening all the time. People (including me) are by definition reckless and unpredictable and nothing is going to change that. There's a reason for that: had we been reasonable all the time no big discoveries would have happened. We wouldn't know about the continents of America, we most probably wouldn't know that radiation is actually bad and finally we'd probably die of hunger had there been no brave hunters risking their lives to master hunting animals.

In today's modern world however we do have the opportunity to make less mistakes - at least less of those obvious ones. And with that let me present you with a definition of two words in German:

Verfügen über - to have the knowledge about something, used in the sense "I do have a driving license"

Beherrschen - to have the ability to do something, used in the sense "I do know how to drive a car"

With those two there's little difference, right? Usually if you do have a driving license you should be capable enough to drive a car. But can you? Is that really what is going on?

Let's try to apply that to software development for a moment. It is obvious you need to study to get the diploma to be a software developer. But does it mean you can do software with it? Can you actually make a living with it? As it turns out yes, you can. The discipline is so vast and by all means so naively taken by so many companies that the moment you step out of school you're ready to go, hot shot! You are the man with the skills. But are you?

In my experience with young graduates and with students it was seldom the case when a young developer right after school was really ready to go. Actually I know only two people that when they came to work at a company with me I felt respect for the wealth of knowledge and humility for things they don't know. And so far it was just the two people I know this far that were open to the suggestion to learn new stuff. There's been sooo many cases where the lack of will to learn new technical skills was demonstrated along with arrogance (not to be confused with confidence) I couldn't even count.

The worst thing about it is they really do get hired! And believe me when I say there are companies where a fresh graduate hired almost off-the-shelve gets the ability to flush the project they are working on literally down the toilette. That means a very young in terms of experience person gets commit access to software that costs hundreds, sometimes even millions of dollars! And we're not talking sporadically - it's how certain companies operate! There's a saying that "there's no person that can't be replaced with a finite number of students". That's how the new markets for software developers came to be.

Obviously in every rule there are exceptions. I know that in the area there are maybe 15%-25% people that really get what software development is all about. And that's actually a very good ratio considering that software development has been announced one of the best paid jobs for graduates and is also viewed as one of the easiest ones in terms of rules.

Yes, rules... What kind of rules are there?

Among those professions I just mentioned there's an MD and a lawyer. Once you're done with your study you don't get to cut-open anybody for any reason, right? You need to gain practice under a trained eye of someone with that experience already there. Otherwise nobody would trust you with a knife doing god knows what to the body of a living soul! Same thing with lawyers. I hope you catch my drift here.

But is it like this with software developers? Do they need to undergo a practice to get certified as software developers that can cut-open (refactor), create and destroy (god-like powers) and provide real value to customers earning big big money for their employers? I think not. I'm sure there are companies that do tend to forbid new hires (freshly out of school or not) to commit anything until they have been long enough with the company to get what they are doing. But it's not always the case. They are hired to do the job, to be resources, not engineers. They are just numbers that mostly do not add up. But there's hope that not everyone is as mad in their doing as the ones I've just mentioned. There's the opensource community that follows exactly the kind of path that it should. You start small, familiarize yourself with the code, maybe submit a patch or two, become a contributor first, gain the trust of other team members and finally if you prove yourself worthy you get the commit access. By the time you get it you'd do harsh things to people for causing harm to the project. I wonder why people do put the information about being a commiter to some opensource project on their CV.. Interesting, isn't it?

More than anything else one needs to remember that software development is about learning and practicing. It's not always something new you need to learn. A lot of times it is something really, really old. Without knowing and above all without practicing it is not possible to "beherrschen" something. Nobody was born with the ability to drive an F1 car. You might "feel it" but you need to train to be good at it. You do need to get your hands dirty!

Have a nice weekend!

The alchemy of software development - part two

In this installment let me walk you through the valley of shadows nobody using computers wants to look at. Let’s have a look at what creating software feels like, what it actually is and why at the end of the day you should care how it’s done.

Software isn’t some forbidden science. It might be hard to understand by mare mortals but it definitely is not something that you can’t do even if you’re not very much into it. But should you? How does it feel like to be a software developer?

Imagine you have this completely obedient servant ready to do everything without hesitation. You tell it to jump of a 100-story building without parachute and it does it. Right down on its face. Splash! Boom! There’s blood everywhere, harsh words,... But nobody cares - it was your servant and you have had complete control over him. The ultimate power! That’s you and the machine. And programmers do that sort of things every minute of every day when they create software. Up to the point when they figure out that the servant lives longer when he has a parachute that actually opens. Sometimes the servant goes haywire and does things the developer does not expect him to do. Suddenly he might refuse to jump even when all the precautions are in place and ready to go. Jump! Jump! Damn it! Then a moment of revelation happens: the developer instructed the servant not to jump if it’s raining, which makes perfect sense. He just didn’t realize the definition of rain was actually not very precise.

The problem with your servant is that he understands only a very specific language. That language has only two words: a zero (0) and a one (1). Fortunately enough scientists realized that ages ago and created human-to-servant translators called compilers. Other mad scientists though that telling your servant to jump without parachute is a bad idea all along and created safe nets forbidding you to do that at all. That’s how runtime environments like Java or .NET came to be... All of the sudden your servant isn’t so obedient anymore. He has more than one master now and your word means nothing compared to the rules enforced by “The Creator”, be it the one that taught you and your servant to communicate or the one that thinks you’re complete moron that needs to be controlled as much as possible.

In the center of all this there’s the programmer. But he’s not alone! There comes the light at the end of the tunnel! The new hope! The solution to every problem he has ever had.. Miracle! A new technology has been created that is supposed to take the pressure of his back. It’s not a few moments later when he realizes that the light he saw was actually coming from a train heading his way and he starts feeling much more like he was before.

The battle continues. Things are getting complicated because some other programmer comes in. The new guy might actually help but he doesn’t speak the language. Well, they both speak English but in a different way. They have different opinions about the side of the building the servant should be jumping from. Finally they agree that going from a corner makes the most sense. After all it’s the fact of landing that counts, right? It’s not the fact of flying itself (even though the most interesting one) but the safe landing that the crowd will observe. So it even makes sense to go a bit crazy and to tell the servant to wait until he’s about half the way through to open the parachute. This way the crowd will be even better entertained and get the result quicker.

There’s that one last thing the team didn’t take into account. The original developer left and with him the original reason for the servant to exist. He was the one knowing all the why’s and how’s about the jump. The rest (and now there’s like a 100 people working the servant) tries really hard to overcome all the tangled cords. Some of the Gordian knots can’t be solved so they cut them out replacing them with new ones, of a different nature, or even leaving the parachute crippled counting on the fact that the remaining strings will still do the job.

Of course since there’s a huge group of developers some of them are more aware of the actual power they have and others don’t. People are different and that’s actually a good thing. From variety comes evolution, right? Well... If you want to jump on a parachute you wouldn’t put your life in the hands of some young inexperienced fast-food assistant, right? After all he knows nothing about jumping! But hey, that’s what happens all the time! After all how the young will learn if not by killing the servant just a couple of hundred times more? That’s not something the more experienced developers like so they manifest their position very strongly. They say they need to be treated like professionals because they “know”. They create manifests, meet to grizzle about colours of the parachute when at the same time their younger colleagues help the servant meet his destiny a couple times more. The servant has many masters. He tries to listen to all of them but there’s just to many. He becomes the hooker trying to fulfill everyone’s dream...

At the end of all this no one knows why the servant needed to jump. That’s perfectly normal and to be expected. The beauty of software development though is that there’s now a servant on every single tall building because everyone wants to have one! It doesn’t matter if you sell condoms or make cars... Just make the freak jump! We need this!

Hope you’ve enjoyed the trip!

Modern state of software development - part one

Throughout the history the software industry has undergone a number of changes in moods, best practices, reinventions of the wheel, reincarnation of old ideas and sunset of countless technologies. Looking back at what has happened in the last two decades in both software development as well as software complexity is really astonishing.

The evolution has truly changed the world as we know it. The foretold End Of The World “scheduled” for this year by Mayan calendar is actually a work in progress. The world as our parents knew it doesn’t exist anymore. Cars are capable of performing maneuvers one had to learn alone (like parking) and it doesn’t take The Great Oracle to be almost certain that in the near future controlling a car will become obsolete all together. Same thing with TV sets becoming not a view-only experience but communication centres, refrigerators controlling the state of food by (almost) themselves or finally cell phones being sold without the capability to make phone calls but with a 24/7 Internet connectivity. All those things exist because there’s a need and all of them are driven by software.

Since the early 70’s the software industry is the single, most energetic part of our western society. The only other one capable of keeping up is its twin brother, the hardware industry. But even hardware is designed with software these days. Ironic, is it not?

In the middle of that is the most incredible, demanding and abstract profession out there, a program writer. Oh wait - we’re not program writers anymore! We are software developers!

That brings me to the merit of this blog series: what is actually software development? Is it really a profession, like a carpenter or shoemaker? A shoe is something I can wear, right? It’s a real thing made of real components. I can use a table made by some carpenter to have the evening meal with my family. Or maybe it’s more like a T-Shirt? But can I touch the software?

Certainly you can have fun with it! Games are the biggest time devourer ever :) I'd argue that if it wasn't for computer games the whole computerization wouldn't take place at all. It's through games that we have shed the fears of our parents about a computer being the Satan's tool of mass destruction. Who knows? Maybe they were right? The fact however remains unchanged that current generation of western civilization can't live without computers. And computers need software...


Have a nice day!

jQuery and posing JSON data to the server

Today a good friend of mine asked me how to post JSON data to the json-rest-api plugin using jQuery. As it turned out using $.post() doesn't do the trick...

Well it's not impossible but very inconvenient if you have to do it a lot. First you need to use the $.ajax() method, not the $.post() one. Secondly you need to specify the contentType parameter for the receiver to be notified that the data is in that format. And last but not least it is crucial to properly serialize your object to string.

The last part can be done using JSON.stringify() but writing this over and over again is painful. Here's a gist (raw) you can use that adds a sister version of $.post called $.postJSON that does exactly the same thing as the original one but sends data in JSON format instead of form post.

Parameters are exactly the same with the single difference that the default expected data format is "json", which makes sense if you're working with JSON services.

Happy coding!