Still working out session details, but it looks like I will be presenting in Ottawa
and Montreal for Techdays 2009. I will
be loitering around at the Toronto event soaking up all the techie-goodness, so come
find me at any of the three events. We can talk shop, shoot the breeze, or just
mill about having a good time.
I promise I won’t embarrass anyone. Except maybe myself. But that’s a
warning for all occasions.
Here are the dates of the events across Canada. Buy your tickets before the
early-bird deal runs out!
Vancouver Convention Centre
Metro Toronto Convention Centre
World Trade & Convention Centre
Hampton Inn & Convention Centre
Winnipeg Convention Centre
The Early Bird price is $299. The regular Price is $599.
I will post more on the sessions I will be presenting at a later date when I get the
See you there!
In the previous post Make it Right I
asked the question
Why aren’t more people making it right?
I was curious why people don’t take the time to write software properly. There
are lots of jokes about bad software development:
If houses were built the same way programmers build programs, we’d all be living on
Unfortunately it’s a fair statement. Most programs out there suck*. I
used to come back with the argument that people have been building houses for thousands
of years, but software for only a few decades. There are bound to be issues.
But then it occurred to me.
Mike Holmes is all about making it right, as I said in the previous post. His
TV show was about fixing the problems that professionals made. Professionals
who have been building the same thing people have built for thousands of years.
Wait a minute. I just flawed my own argument.
Houses are built the same way programmers build programs.
I see three very apparent reasons.
Cheapness – People want software built quickly, as cheap as possible.
Laziness – Why strain your mental processing or follow best practices when you can
just do whatever first comes to mind?
Uneducated – Sometimes (a lot of times) the person doing the building/development
just doesn’t know what they are doing.
There are numerous other reasons why, but these three are by far the biggest across
all aspects of building stuff. I think they answer the basic question asked
earlier, but now I have another question.
Why do we let people who are lazy or uneducated build applications for us, just so
we can save a few bucks? We will end up paying loads more in support after the
*I said programs, not programmers.
For the last couple months I’ve had a strange fascination with the TV show Holmes
on Homes. By no means am I construction-literate. When I want something
built with wood, I buy it. The fascination is not about the construction, or
even his manly good looks (FYI: I meant it in the friendly-way, not the friendly-way),
but the premise of the show.
Mike Holmes is about doing a job right. It doesn’t matter what the job is; it HAS to
be done right. Period. No if’s, and’s, or but’s. We need more people
This applies to Information Technology as well. Take the Security
Development Lifecycle for example:
Do it right first: securing new code helps keep down compatibility and roll-out costs.
Why aren’t more people making it right?
Good enough is sometimes not good enough. I’ve been doing a lot of thinking
lately (well, I’m always thinking), and security has been an issue that has come up
a lot. Frankly, I’m a two-bit software developer. I know my code isn’t
the best, nor the most secure. I use strong passwords, encrypt my sensitive
data, and try to limit access to the applications for those who need to use it.
In theory this works. Problem is, it’s a lame theory. There are so many
unknown factors that have to be taken into account. Often times they aren’t.
When I go to build an application I spend time designing it and architecting it.
This is usually the case for most developers. What I’ve noticed though, is that
I don’t spend time securing it. I can’t.
Imagine building a house. You put locks on the doors, bars on the windows, and
someone breaks in. Why? Because someone left the key in the door.
You can’t build against that. You just can’t.
You can follow the Security
Development Lifecycle, which I recommend to each every single developer I meet.
There are tons of resources available.
But it can only go so far. It’s designed more for being part of the iterative
processes, not the architecture. Or at least, that’s how most people interpret
My last post talked about Single
Sign-On (SSO). It’s a great sellable feature for any product. What most
people don’t realize though is the inherent security benefit to it. With it,
that means one less password to remember, one less password that could get intercepted,
one less password to change every month. This is a fundamental architectural
issue. But at the same time, it’s common sense.
What is sometimes the simplest idea, is usually the correct solution
What the hell does that mean? It means keep it simple. Security is simple.
Keep data from prying eyes, and keep it from getting lost. This is common sense.
Security is not difficult to comprehend. It becomes difficult when academics
get involved. Spouting theories and methodologies scares people into thinking
security is extremely difficult to implement. It’s not!
Follow the Data
Understanding the flow of data is crucial in properly architecting an application.
It’s crucial in properly securing an application as well. SSO
is a perfect example of this.
The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end
data systems. Using SSO, you can access data from server computers and services that
are external to Office SharePoint Server 2007. From within Office SharePoint Server
2007 Web Parts, you can view, create, and change this data. The SSO feature ensures
It makes perfect sense. It’s simple when you think about, and it affects every
subsystem of SharePoint. Make security a feature.
I’m fairly certain there’s a good reason for this, but I just thought it was interesting
because these are not hashes. They are actual encrypted passwords. Statistically
improbable to get something like this in production systems. Completely understandable
in development. Just thought it was interesting to see.
In my previous post, I started
talking about using Microsoft technologies over PHP and open source technologies.
There were a couple reasons why I chose to make the move. First, from a development
perspective, everything was object oriented. PHP was just getting started with
OOP at the time, and it wasn’t all that friendly. Second, development time was
generally cut in at least half, because of the built in controls of ASP.NET.
Third, the end result was a more rich application experience for the same reason.
The final reason comes down to the data aspect.
Pulling data from a database in PHP wasn’t easy to do. The built in support
was for MySQL, with very little, if next to nothing for SQL Server. In a lot
of cases that isn’t always a bad thing. MySQL is free. You can’t argue
with that. however, MySQL wasn’t what you would call ACID compliant. Defined,
MySQL did not have the characteristics of being Atomic, Consistent, Isolated,
and Durable. Essentially, when data goes missing, there is nothing you can do
about it. SQL Server on the other hand is very ACID compliant. This is
something you want. Period.
Once .NET 2.0 was released, a whole new paradigm came into play for data in a web
application. It was easy to access! No more, or at least next to very
little boiler plate coding was necessary for data access now. Talk about a selling
point. Especially when the developer in question is 16 going on 17.
Now that I didn’t need to worry about data access code, I could start working on figuring
out SQL. At the time t-SQL scared the crap out of me. My brain just couldn’t
work around datasets. The idea of working with multiple pieces of data at once
was foreign. I understood single valued iterations. A for loop made sense
to me. SELECTs and JOINs confused me. Mind you, I didn’t start Statistics
in math until the following year. Did SQL help with statistics, or did statistics
help me finally figure out SQL? It’s a chicken and the egg paradox.
So here I am, 17 years old, understanding multiple languages, building dozens of applications,
and attending developer conferences all the while managing my education in High School.
Sweet. I have 3 years until the next release of Visual Studio comes out.
It was here that I figured I should probably start paying more attention in school.
It’s not so much that I wasn’t paying attention, it’s just that I didn’t care enough.
I put in just enough effort to skate through classes with a passing mark. It
was also at this point in time that I made an interesting supposition.
Experts tend to agree that people who are programming geniuses are also good at math
and critical thinking or reasoning. Not one or the other, but both. Now
I’m not saying I’m a programming genius, but I suck at math. It was just never
in the cards. But, according to all those High School exams and the psychological
profiling they gather from them, my Critical Thinking and Reasoning skills are excellent.
Top 10% in Canada according to the exam results. My math skills sit around top
20-30% depending on the type.
Neurologists place this type of thinking in the left hemisphere of the brain.
The left brain is associated with verbal, logical, and analytical thinking. It excels
in naming and categorizing things, symbolic abstraction, speech, reading, writing,
arithmetic. Those who live in the left brain are very linear. Perfect
for a software developer.
The supposition I made had more to do with the Pre-Frontal Cortex of the brain.
It does a lot of work, some of which is planning complex cognitive behaviors.
Behaviors like making a list, calculating numbers, abstracting thoughts, etc.
It plans out the processes our brains use to get things done. This is true for
both sides of the brain. So, suppose you are left brain-oriented. You
are predisposed to be good at development. Now, suppose your Pre-Frontal Cortex
is very well developed, more so than the average person. It could be reasoned
that part of being a programming genius is having a well developed Pre-Frontal Cortex.
So why does this make us want to program? Find out in Part