Software ever changing truths

Quite often in software [development] (more often than not?), as time goes on, what is truth, becomes not truth, and this is possibly one of the reasons it makes software development so difficult, human brains are normally trained to learn stuff, but are not trained for dis learning and that's where the problem resides, as humans, once we learn something a certain way and we learn that that is good (or "the best way"), it is very difficult to change our minds to do it differently.

Programmers are frequently questioning what is the best way to do x or y, in many cases people will grab the first result from a web search (sounds familiar?), take that as the absolute truth, apply it to whatever problem they are solving and move on with life, though other times the ramifications of such learning experience will carry over much further, maybe the person will write a blog post about it or teach his/her co-workers, thus distributing the knowledge.

Keep in mind that is not always about finding out the best way of doing things,  some other times we find out that something is not possible, and this last one might be worst, more so on young developers, learning that something is not possible is very dangerous, have you seen an elephant tied to the tiny stake? it has learned that as soon as it reaches the end of its rope, it can't go any further.

Many of these truths come from respected authorities in the world of software, maybe from the software vendor itself or the official community around it, making matters even more complicated because they are the source and you trust them. The key here is not that you can't trust anyone, it's only that you should not lock that into your brain as the absolute truth, software is always evolving, it's always changing truths.

There are few things that you should take as the absolute truth though ;), among them:

• There's usually no best way of doing things, there's only a better way(s) of doing it.
• Software development is not black or white, in fact I think most of it is gray area.
• There are no hard rules in software development, it'd be too easy if that was the case. 
• There is no such thing as an impossible thing, only incapable beings.
  
• Software is always evolving, what is truth today may not be the truth tomorrow.

All I am saying is that whenever you come to "the best way of doing" (be it an algorithm, a technology, framework or methodology), a performance comparisson that shows that X is better than Y or something that is "not possible", it doesn't matter who it comes from, take it with a grain of salt. What is truth today may not be truth tomorrow.

Information disclosure: It's everywhere

You might have seen stickers like this in the back window of some minivan and maybe you thought it was funny/cute/stupid, but did you ever think of it as information disclosure? What's the big deal about showing all of your family's names? glad you ask :), let me briefly describe something that happens in Mexico and South America: Virtual kidnapping extortion, criminals will call your phone, tell you that hey have kidnapped your kid (they have the names you graciously provided) and ask you to immediately pay the ransom, when in reality they don't have your kid, but use the emotional momentum to take advantage of you. This is only one example of how they conduct these activities, there are many other ways, and I'm not trying to make you scared of that, but to make a point on information disclosure. It can be found in the most innocent places and if you think this can't happen to you, then you're already very vulnerable.

You've also probably seen this:

I couldn't even tell you how many blogs have been hacked because of that (hint: too many), WordPress makes it too easy to break those sites when new vulnerabilities appear (as they do every other week).

I have seen systems where they use some employee id as their login credentials, that id is visible when the computer is locked, and it turns out you can call the help desk, provide them with that id, the person's name, and they will happily reset the password for you.

Unfortunately there are no rules that I can give you or that I have ever seen anywhere to prevent the issue of information disclosure, I'm just trying to raise the awareness on the potential issue that represents having information that bad people can use for malign purposes both in your systems and your own life. The only thing I can tell you is that information disclosure is really everywhere, in your comments, in your configuration files, disclosing the components that your app users, that version, that user id, etc. even in that innocent sticker.

Security does get in the way of usability and usability gets in the way of security, just give it a second thought and be careful out there.

There is no such thing as a secure system, all you can do is raise the bar a little bit more and yes, security by obscurity may be your friend some times.

Duct tape programming: Elegant code doesn't pay the bills

Finally decided to jump into the Duct Tape programmer conversation that's been around the internets for the last weeks; talk about flame wars! a large portion of the blogging/twitter community took this post as an attack on TDD, Agile development practices and overall quality software development; which makes perfect sense if you think about it, that's what they sell, that's what they blog and tweet about all the time, so, Joel's post hit some sensitive nerves there. All of those patterns and practices fanboys are trying to convince the world that the duct tape programmers are those who don't care about quality and that they are just writing software that is not maintainable, extensible and all those things that we expect from good software. Those are the same people that quickly dismiss content that is "purely technical", you'll see them talking and talking all the time about good patterns and practices, but not so much about implementations of anything down to the actual code level. I say, theory is good, but without the practice, it's useless.

Unfortunately for them the very first example of duct tape programming that jumps out is StackOverflow, a site that has been developed by self acknowledged duct tape programmers, but also a site that has proven to be fast, reliable, and has delivered tons of features over time, which tells me the code is very extensible; I'm sure the code is not something your average programmer could get a grasp of and would probably make purists throw up a little bit here and there, but is code that does what it supposed to do, and does it very well (do I hear ship it?)

When I stated that in Twitter about SO, some didn't believe it (which tells me they thought it was so good it couldn't be duct tape programming, but there are podcasts you can look for and listen to what they have done), and someone else madly replied to me, arguing that SO was the only real example of successful duct tape programming, unfortunately for them (again) if you look at the tremendous success on Apple products lately, you'll see duct tape programming all over the place, Apple is the King (or Queen?) of duct tape programming, specially the iPhone development ecosystem, it's not all that pretty but Apple has always delivered what people want, you may read my own blog about many stupid things that Apple does, but on the end, people are very happy with their products, and that's all that matters, people don't care that the underlying infrastructure or the code for the apps looks like crap, I'll say it again: it doesn't matter.

The biggest problem with purists is that when you focus on making every single line of code fit within a pattern, it's very easy to cross the line of over engineering and forget about the very basics of software development, which is, it has to meet your customers expectations, and you have to deliver, if you don't deliver a product, it doesn't matter how good the code is, unfortunately elegant code doesn't pay the bills, getting the job done does.

A brute-force solution that works is better than an elegant solution that doesn't work. Code Complete 2

My most frequent pattern is "whatever works", I'm not afraid of throwing in procedural, OOP, functional, dynamic, stored procedures, you name it, whatever gets the job done (ok, except for XML, I hate XML) in a way that works and allows me to extend that code later, but most importantly, I am used to delivering good results, always, no excuses, you'll often hear me say, is not an option, it HAS to work. Don't get me wrong, I'm very strict with my code, I like elegant code, I follow good SOLID principles, I write unit tests when a piece of code definitely needs it, is just that I don't force everything into a pattern, I don't always write my tests first religiously (ok, actually, I never write the tests first, I think it's stupid). That for me, is the duct tape programmer. You just have to know when to pull the plug and keep in mind the most important feature of your product. Shipping is that feature, without it, whatever you do, even if it is a master piece, is worthless.

Now, when you corner purists showing them good results from duct tape programming, they argue that it takes very talented people to pull that off, sure, nobody said it was easy, it takes talent, it takes reading and understanding all those "purely technical content" entries, experimenting, playing, hacking, on the end, software development IS a people problem. I think methodologies are for people who don't have the talent, but that's a whole different topic.

There are no hard rules in programming, it would be too easy if that was the case.

disclaimer: I took the "elegant code doesn't pay the bills" phrase from someone in Twitter, sorry, can't find it now.

Programming is like Chess

For a long time I have believed that software development is just like a Chess game, but apparently not many people have thought about it this way, just *bing* it and you'll see less than a page of results (Google is no better), of course this is about to change as I write this post and everybody sees the light... or not

anyway, let me elaborate on my analogy

The bad programmer
Arguably the average programmer, makes a move without thinking about the side effects, his capacity of analyzing problems is not all that great, there are so many side effects (breaking code, introducing bugs, security, etc) but this guy is not even aware of most of them, he basically relies on the debugger and if it runs on his machine then is good to go; when stuff inevitably breaks he just goes back and makes another move that seems to fix the problem, if you give this guy a large project it is likely that he'll make a stupid move that will just cause Checkmate on the project

The good
Analyzes different paths and choses the one he thinks is best, this player can play a good game, every once in a while his analysis is not that through and makes some mistakes but he can learn from that, this guy usually delivers good quality software with few bugs that he can go back and fix quickly enough to be acceptable

The best
This guy can make a whole bunch of moves all in his head, he's informed about all the latest techniques to defeat the opponent but he doesn't just rush and use them in a game, he tries them first on his own little projects and ends up using the ones that he proves to be useful, the ones that are shorter, quicker and give him the best return, he knows the techniques to use with the small projects and the ones to be used with large projects, and he knows they are very different, this guy knows what the opponent is thinking, he knows what the opponent will respond to every one of his moves so he usually chooses the best move... he knows the side effects; the "works on my machine" is not on this guy's vocabulary.

As you can see the the main two differences in my analogy are the capacity of analysis (selecting the move) and the awareness of the side effects (what happens when you make that move).
The opponent is your software project, the move is writing the code, the side effects are everything else that is affected by that.

When was the last time that you introduced a new bug fixing that other bug or writing some new functionality? or when *they* found bugs of your code right after it went to production? or when it worked on your machine but not on the server?

Every time you make a move, stop and think about the side effects, there are always side effects, if you can't think of them, there are tools that can help you think better, such as Unit Testing, the more you practice it, the better you'll get at it, I promise

programming practices: never say never

Jan Bannister wrote this post: bool considered harmful, and writes:

Never Use Bool, or more specifically never user bool as a parameter. It is the most foolish of datatypes and conveys the smallest amount of information possible.

I can disagree with that in a number of ways, but the culprit was the "never use bool as a parameter", the biggest problems I see
- you would end up with hundreds of enums to replace your bool parameters, and then
- where do you put all those enums?
- at some point you would probably duplicate some of the required functionality

so, what do we do, bool is still "harmful", but not always, that's the key, I can think of at least 2 situations where you don't necessarily need to replace your bools with enums
- private methods: they are (hopefully) only used in that class... and the method is not that big, and the class is not that big, and you added comments for the method/parameters... sigh...
- functions with a single parameter that is just an on/off thing, e.g. SetVisible(true)

there, now it doesn't sound that bad, bottom line, never say never, don't abuse any technique

is not about the pattern, it's about the practice

There's a discussion going on in the blogosphere about "bashing patterns", Corneliu (parallel thinking) says:

This month seems to be the month of bashing the singletons and some of the other design patterns.

From posts like Singleton Considered Stupid to Singleton – the most overused pattern and Criticism on one the Patterns (Blog 3), the blogo-sphere is full of comments about why singleton is bad or evil.

I don't think the problem is with the use of the pattern, but with the abuse of them; but this has always been the problem in programming in general, most of the time programmers learn a few things just to "get things working", and as long as it works "if is not broken why fix it".
Is it all the programmers fault? I don't think so, I think it has to do a lot with management requesting things to be done by yesterday (bad estimates), but that's another topic which has been discussed quite a lot already

so this is not a new problem, is the same old problem (abuse of techniques) applied to the patterns, the patterns are good, the implementation may be correct, but the usage (the practice) of them is the problem

why the singleton? I think because that's one of the "easiest" ones, you can pretty much copy and paste it, you don't even need to understand the inner workings, you just know that "it will be a single instance of your class", and that's something you can't do with other patterns

we need to teach better usages, better practices.

let's all just develop ASP.NET in notepad / is not about the tools

Jeremy Miller started a conversation on .NET testability (or the lack there of), Ayende agrees with him

I can definitely see this, I have suffered from this... but!

I don't think the problem is with the tools, in any case the problem would be of the TDD community, Ruby on Rails is open source, why can't we create asp.net on steroids?
seems like we know exactly what we want, the concept is there, the code is there, just needs to be implemented in .NET

there was a provocative comment to Jeremy's post:
"What if I want RAD and I don't want tests?"
there are some strong arguments against this, but the truth is for most developers that's all they want

everyone can say X sucks, Y in this other language is much better, why can't we say let's create Y for asp.net?

would people really use it? or is this just a TDD religion thing? (I'm gonna get in trouble for this)

I'll tell you what, that's exactly the reason why Microsoft didn't put something like that in ASP.NET, TDD advocates are not the broad audience, the majority of the "developers" don't really know or care about TDD or refactoring or patterns and practices, they just "want stuff to work", and yes, the rest of us have to pay the price, but nobody is forcing you to use RAD if it doesn't work, you have to use the right tool.

I can agree with this:

I really think the .Net community needs to reexamine and debate the merits and appropriateness of the Visual RAD approach.

the key here is the .NET community, people keep asking Microsoft to solve all these problems, are these problems really the developer's problem? or is it just TDD community problem? how big is that community?, where is the community? why can't that community do it? let's stop blaming it on something else

is kinda late, I was just kidding with Notepad and I've just hit another trip around the sun...

time for a refactorer job title

from Jeff Atwood post code smaller

It's up to us to resist the natural tendency of any project to snowball into a giant rolling Katamari ball of code. Code smaller!

for the last 4-6 months I have eliminated about 3-5 times more code than I have written (maybe more than that!?), specially using generics, as everything else in life (hopefully) you get better at it the more you do it.

but I have seen this problem over and over again in many different teams, and the sad part is that the problem is not specific to new developers, experienced developers keep doing it the same way

It seems is time for a new job title whose primary responsibility is to refactor code, and the members of the team should learn from him and start to follow

of course the actual job title would have to be much cooler than "Refactorer"