The understanding dilemma

Remember the first time you heard about object-oriented programming?  What was your first response?  If you're like me (and most other people), your response was probably something along the lines of "What the heck is this?"

Yet, at one point, a lightbulb probably clicked in your head.  All of a sudden, it made sense.  Nowadays, I know objects like the back of my hand.  It's just such a simple concept, is it not?

How many times has something similar happened to you?  I'm willing to bet it's more common than you think.  The thing about it is that we as humans have a tendency to assume something we don't understand is complex.  And oftentimes that's true.  But sometimes it isn't.

I think I've determined the root cause of this problem.  You see, we programmers have to be masters of filtering out unnecessary data.  There's simply too much of it.  So how do we approach learning new things?  We try to learn the bare minimum.  Most of the time, this is necessary.

Here comes the bad news.  This doesn't always work.  You were expecting me to say this, weren't you?  You see, there are times where we as programmers have to understand things.  And by understand, I don't just mean extracting just the parts you feel are necessary.  I mean you have to understand general concepts.

After all, only an idiot would claim that the only part of C you need to know to write a calculator are the +, -. /, and * operators.  And yet, this is what we as programmers find ourselves doing on a daily basis.  We momentarily ignore the fact that we need to know how to write a function and how to do I/O.

The point is this:  just make sure you understand things before you pass judgement.  And try to make sure that you spend time understanding general concepts and not just specific ones.
Loading mentions Retweet

Comments [0]

How programming language webpages should be designed

A while back, I asked a question on Stackoverflow that taught me something (other than what programming languages are fun to work with). A lot of programming language authors just aren't very good at marketing their languages.

There are a lot of programming languages out there that I wanted to try out, but couldn't figure out an excuse to spend my time on them. And that's pretty sad considering how much I like trying new languages out.

Therefore, I'd like to present to the world my ideal website for programming languages: the Ruby webpage. In fact, I have to admit that if I were trying to decide between Python (my favorite programming language) and Ruby today, I'd easily choose Ruby just based on their website. And that would be sad considering that I love Python so much more than Ruby (but that's just a personal preference, nothing against Ruby).

Let's take a look at why this is.

Show me the code!

I still don't understand why this is such a difficult concept for some programming languages. The first thing I want to know is how my code
will look if I write it in your language. With Ruby, it's right there on the first page.  Now try doing the same thing on the Python webpage.  Not as easy is it?

Even if you don't want to put it on the first page, it should at least be reachable using one click on the first page.  See the Scala webpage for an example of this.

Feature lists are useless, documentation is priceless

Hey, your language is cross-platform, has object-oriented and/or functional and/or concatenative and/or [insert language buzzword here] features. Good for you! Since you've taken a whole lot of time to provide me with great features, show them to me.

Again, I hold up Ruby as a prime example of how to do this. Right on the front page is Ruby in Twenty Minutes. This shows me all of the great features in brief code examples. And if that doesn't work for me, I can even try Ruby out in my browser.

As an example of how not to do this, I present the Unicon webpage. From the front page, I can gather that Unicon is a "very high level, goal-directed, object-oriented, general purpose applications language", but that's about it.

But we just met!

And one other thing, don't try to sell me a book. Yes, you should make it easy to find books on your programming language. No, you shouldn't remind me of it every chance you get. I view suggestions to buy a book as being somewhat like asking me to move in with you on the first date. Yeah, I find you interesting. I'm just not ready for the commitment.

Loading mentions Retweet

Comments [5]

7 tools for working with Python in Emacs (and Ubuntu)

I've been meaning to blog about this for some time, so I suppose now
is as good an opportunity as any. This is going to be a very "stream
of consciousness"-esque posting, so bear with me. Some of these are
things that have radically changed the way I use emacs. Others are
minor changes that I like. Feel free to pick and choose from them.

I'll assume you're running Ubuntu. Also, not all of these are Python
specific. But I feel that they will be useful to most Python
programmers who use emacs.

I should also note that (like most emacs users), most of these things
are tricks that I've picked up from various sources along the way. If
you wrote something that I put in here, thanks!

Ropemacs

Ropemacs is among the tools I love the most and hate the most. When
it works, it opens up a new world of automated refactorings for you.
But it seems to be a bit buggy at times. That said, setting it up is
really easy. Firstly, you need to have ropemacs installed. This is
pretty easy: 

 
sudo apt-get install python-ropemacs

After that, just a couple of lines of elisp in your .emacs file and
you're good to go! 

 
(require 'pymacs) 
(pymacs-load "ropemacs" "rope-") 
(setq ropemacs-enable-autoimport t)

Anything

Anything is almost like Quicksilver for emacs. To begin, you need to
download anything.el and anything-config. I also use 
anything-match-plugin. Then you just need the following lines of elisp: 

 
(require 'anything-config) 
(require 'anything-match-plugin) 
(global-set-key "\C-ca" 'anything) 
(global-set-key "\C-ce" 'anything-for-files)

Then, prepare to spend a lot less time searching for files!

Line number mode

When you're pair programming, nothing is more helpful than being able
to direct people to a certain line of code. This lets you spend less
time saying "hey, see that over there? It's about 3 lines up. No,
too far! go down another two lines." Installing this is really easy.
You just need linum.el and two lines of elisp: 

 
(require 'linum) 
(global-linum-mode 1)

Flymake through pyflakes

In case you miss the automatic error highlighting of the Visual Studio
world, you should realize that emacs has a similar system built-in.
It's called flymake. And you can make it work with Python as well. I
personally prefer to use pyflakes for this. All that's needed is
pyflakes: 

 
sudo apt-get install pyflakes

...and some elisp: 

 
(when (load "flymake" t) 
 (defun flymake-pyflakes-init () 
 (let* ((temp-file (flymake-init-create-temp-buffer-copy 
 'flymake-create-temp-inplace)) 
 (local-file (file-relative-name 
 temp-file 
 (file-name-directory buffer-file-name)))) 
 (list "pyflakes" (list local-file)))) 
 
 (add-to-list 'flymake-allowed-file-name-masks 
 '("\\.py\\'" flymake-pyflakes-init)))

Uniquify

How many __init__.py buffers do you have open at this moment? If
you're using emacs for Python programming, probably a lot. This is
where emacs's uniquify functionality is useful. It gives you a more
useful name for your buffers other than just appending a number at the
end. I have mine use the reverse of the directory. For instance, if
I have foo/__init__.py and bar/__init__.py open, they will be named
__init__.py/foo and __init__.py/bar respectively.

You just need this in your .emacs: 

 
(setq uniquify-buffer-name-style 'reverse) 
(setq uniquify-separator "/") 
(setq uniquify-after-kill-buffer-p t) ; rename after killing uniquified 
 
(setq uniquify-ignore-buffers-re "^\\*") ; don't muck with special 
buffers (or Gnus mail buffers)

python-mode

To be totally honest with you, I haven't used the built-in emacs mode
for python. I just installed python-mode because I was told it was
better. What I can tell you is that there is an occasional plugin
that requires python-mode. Installing it is easy. Just install
python-mode: 

 
sudo apt-get install python-mode

And add some elisp: 

 
(autoload 'python-mode "python-mode" "Python Mode." t) 
(add-to-list 'auto-mode-alist '("\\.py\\'" . python-mode)) 
(add-to-list 'interpreter-mode-alist '("python" . python-mode))

Pylookup

Pylookup is useful for those moments when you find yourself asking
something like "Is join in os or os.path?" Unfortunately, the setup
can be complex, but well worth it. There are instructions here.

     
Click here to download:
7_tools_for_working_with_Pytho.zip (49 KB)

Loading mentions Retweet
Filed under  //   emacs   python   ubuntu  

Comments [3]

The devil's in the details

There are two schools of thought in the programming world:

  1. Explicit is better than implicit (configuration over convention)
  2. A developer should only have to program the unconventional aspects of a program (convention over configuration).

We'll call #1 the Python school and #2 the Ruby school. In fact, I
would argue that this is an issue that's at the core of whether code
is considered "Pythonic" or "Rubyic" (I doubt the last one is a word).

So which school of thought is right? I personally think they both
are. It doesn't really take a whole lot to demonstrate that the
Python school of thought isn't always right. Think about it. Did you
know that the Python runtime has a component that goes around deleting
objects from memory totally implicitly? How unpythonic is that?

The Ruby school of thought takes a bit more work though. After all,
if it's unconventional, why should you have to configure it? Of
course, the problem here is in defining "conventional". What's
conventional to me is likely unconventional to others. And what's
conventional to others could be unconventional to me.

I wish I had more advice on how to reconcile these two schools of
thought. The truth is that I struggle with them daily. But I think
having an intuition about this is the dividing line between
"experienced programmer" and "newb". After all, if programming were
merely about "make everything explicit" or "make everything implicit",
any idiot could do it.

I think this is also the core skill for writing readable code. You
need to determine what details are relevant to each piece of code.
Whatever the case, you need to make a conscious decision as to what
details shine through and what details you obscure. Because if these
things happen on accident, they're almost guaranteed to be wrong.

Loading mentions Retweet
Filed under  //   programming   python   ruby  

Comments [1]

Persistence is a subset of immutability

Whenever I tell someone I'm working on a persistent data structure 
library for Python, I almost always get the same response: 
"Persistent means that something is stored across process boundaries. 
I think you mean to say immutable data structures."  In fairness, this 
response is understandable.  But it's not quite right.  I'm going to 
address both of the points in the above statement. 


Persistent means that something is stored across process boundaries


Did you that letter can mean a note you send through the mail or a thing you use to make up words?  Did you know that programming can mean writing computer programs or mathematical optimization?  I'm sure if I sat down long enough, I could think of more examples.  The point is that the language we speak is full of ambiguities and whatnot. 

Before we consider the computer science meaning of persistence, let's 
look at the common meaning.  If we look at the word persistent in 
Merriam-Webster, the first two definitions we run into are: 

1 : existing for a long or longer than usual time or continuously: as 
a : retained beyond the usual period  b : continuing without change in 
function or structure 

The meaning Python programmers tend to think of is the definition in 
part a.  That is, a persistent data structure is stored beyond the 
usual period (the process's lifespan).  However, when I talk about a 
persistent data structure, I tend to mean the definition in part b. 

Going with definition b, we can see that lists for example aren't persistent: 

 
>>> a = [1,2,3] 
>>> b = a 
>>> b.append(4) 
>>> a 
[1, 2, 3, 4] 
 

Tuples, however, are a different matter: 

 
>>> a = (1,2,3) 
>>> b = a + (4,) 
>>> b 
(1, 2, 3, 4) 
>>> a 
(1, 2, 3) 
 

Ah, but here's where the second part of this post comes in.

I think you mean to say immutable data structures

In the case of the tuple, you are correct to say that a tuple is 
immutable.  And I'm correct in saying that a tuple is persistent. 
Just like I'd be right to say that I own a car while someone else 
claims that I own an automobile.  However in both cases, they can't 
quite be used interchangeably.  After all, an automobile isn't 
necessarily a car.  It can be a truck or a van or an SUV. 

In the same sense, a persistent data structure is effectively 
immutable.  But an immutable data structure isn't necessarily 
persistent.  Let's consider the definition of both of these words from 
wikipedia: 

Immutable object


In object-oriented and functional programming, an immutable object is 

an object whose state cannot be modified after it is created. 


Persistent data structure


In computing, a persistent data structure is a data structure which 

always preserves the previous version of itself when it is modified; 

such data structures are effectively immutable, as their operations

do not (visibly) update the structure in-place, but instead always

yield a new updated structure. 


These definitions have a lot of common ground, but there is some 
difference between them.  Let's consider a data structure that is 
immutable but not persistent.  Prepare yourself.  This will be 
complex.  Ready? 

 
>>> 1 
1 
 

Has your mind been blown yet? 

In this sense, the number 1 is definitely immutable.  You can't change 
it.  It's always the number 1.  However, it's not persistent.  How do 
you update the number 1?  No matter what you do, it will always be the 
number 1.  Sure, you can get 3 by adding it to 2.  But in a 
mathematical sense, that's not really changing the number 1. 

In this sense, the number 1 is atomic.  It simply doesn't make sense 
to modify it.  Heck, you can't even copy it: 

 
>>> from copy import copy 
>>> a = 1 
>>> a is copy(a) 
True 

Conclusion

With this semantic difference in mind, remember that it's just that: 
a semantic difference.  Call them Bob if you want to.  However, bear 
in mind that when someone uses the word persistence in this way, 
they're not being inaccurate.

 

Loading mentions Retweet
Filed under  //   functional-programming   persistence   programming   python  

Comments [0]

The other side of being a free electron

So my last blog post on the subject of free electon programmers seems to have been successful.  I've gotten responses in two forms:

  1.  This is so self-serving.  What about the other people on your team?  They have a special personality as well!
  2.  This really hit home with me.  But I still don't really feel like it's really helped me much.
My response to these points:  I couldn't agree more!  Here's the thing though:  it's much more difficult to say what other people want.  On the other hand, what better expert is there on what you want than yourself?  That was kind of the idea behind my last post:  "if you're struggling with somebody who has a personality like this, here's what you need to understand".

That said, I've learned a thing or two in my time that I think I can share.  Although this is mostly related to free electrons, a lot of this is useful for any programmer.

Other people have emotions

If I had to choose one area where INTPs and INTJs have the most difficulty, it's here.  This goes beyond your typical geek social idiocy.  Heck, it hasn't been more than a decade since it actually hit me that other people expect me to acknowledge their feelings.  Now I know this feels dumb.  And yes, you'll still forget.  But you'd be surprised at how much this helps you get along with people.

You see, people expect you to react in certain ways when they say something.  When they tell you a story about something that's exciting to them, show some interest no matter how inane it sounds.  When people are angry about something, empathize with them and try to find some common ground even if it's difficult.  If it's you they're angry at, resist the temptation to respond in kind.  If you're calm and rational about it, people will usually be willing to have a calm and civil discussion about things.

And this is the most important part:  if you did something wrong, apologize.  I know this can be hard, but if there's one thing that's never ceased to amaze me, it's humankind's capacity to forgive and forget.

It's a good thing that other people don't understand you

We've all been there before.  You have to spend an hour's worth of your time explaining the simplest and most benign thing in the world to someone else who just doesn't get it.  If the person is truly an incompetent idiot, you should be discussing things with your manager.  Otherwise, you should take the person's bewilderment as a complement:  you understand something they don't and they want to learn from you.  After all, if they really didn't want to learn from you, they'd probably just ignore you.

In fact, you'd do well to take a page from their book.  Next time you find yourself feeling that someone else's opinion is the stupidest thing ever, don't criticize them.  At least not immediately.  Instead, ask questions to get at why it is they feel the way they do.  You never know, they could have seen something you haven't.  You see, not only is it a good thing that people don't understand you, but it's also good that you don't understand other people.

Fight the urge to always go it alone

Most of the time, it's easiest for me to just go off on my own for a week or two, code something, and come back when it's done.  The thing is that I almost always end up with something that nobody else really gets.  You don't have to be joined at the hip with the entire team all the time.  But it's helpful to just spend some time at least explaining your code to someone else.  This is good even if for no other reason than it helps you learn what trouble other people are going to have with it.

Code reviews are really awesome for this.

People like you

Yes, even when you're being a jerk.  There have been several occasions where I've gotten into some rather heated arguments over mundane issues with people that were admittedly my fault.  And not once has anyone died because of it.  You see, if I had a choice between working with people who disagreed with everything I say or working with people who love all of my ideas, I'd go with the argumentative asshole every day.  People who think critically about other peoples' ideas are a rare asset for a software company.  And your coworkers will appreciate this if they truly want to do their jobs.

Choose your battles

Free electrons have a very ordered way of looking at the universe.  We tend to get frustrated if something disturbs that way of thinking.  And that's led me to some long arguments.  

Next time you get into an argument with someone, ask yourself this:  "If I just let this person win, how big of a deal will it really be?"  If your answer is "not a big deal", then just let them have their way.  If you can't answer the question, then you probably are arguing over nothing and should let them have their way.  

However, if your first instinct is "this is a huge deal" and you can explain why, then stick to your guns as much as possible.  Generally, people will be willing to cede the important fights to you if you stick to this strategy.

Conclusions

Admittedly, I'm borderlining on making free electron programmers the new "duct tape programmers".  If that's the case, then so be it.  If there's one thing that nobody can say about Joel Spolsky's piece on JWZ, it's that people didn't consider his way of thought.

However, I'd like to hear feedback.  What other piece of advice do you have for programmers like me?  Is there anything else that I'm missing or getting wrong?
Loading mentions Retweet
Filed under  //   programming  

Comments [0]

The "free electron" programmer

I have to say that I really liked reading Rands in Repose's excellent blog post about "free electron" programmers.  Unrelated side note:  Did you know that Simply Hired has a graph showing the median salary of these kinds of programmers?  Apparently the median salary is around $78,000.

At any rate, I feel that this is a subject I can add to.  I say this because I consider myself a free electron.  And I'm not saying that to be cocky either.  It's just that Rands's description of the free electron is almost a word-for-word description of the Architect (INTP) or maybe the Mastermind (INTJ) personality type.  I just so happen to be an Architect. I think that people with both of these personalities were almost born to be programmers.  They're naturally inquisitive and love nothing more than to understand complex systems.  But they can really be destructive if not dealt with properly.  And they're so rare (about 1-5% of the population) that many people may simply be unaware of how to deal with them.

At any rate, here is a list of general pieces of advice to get along well with your free electron (in no particular order):

Listen to them

Alright, so I lied when I said this was in no particular order (at least for this point).  This is the single most important thing to do to get the most use of your free electron and to keep your free electron happy.  Yes, we come up with some rather zany ideas that seem to not be grounded in reality.  And a lot of the time, that may be true.

But you also need to understand that free electrons have an unmatched ability to understand complexity.  This means that oftentimes, they may understand something you don't.  And sometimes, it is difficult to put complexity into words.  Thus, what seems like a zany idea to you might actually be a perfectly rational way of looking at things when you understand all of the details.

But you shouldn't just listen to them when they're right.  You also need to give them thoughtful consideration when they're quite obviously wrong too.  Nobody likes not being listened to, but free electrons hate it worse than anyone else.  And more to the point, they're driven to make people listen to them by whatever means are available.  If this leads to an overly long and drawn-out discussion of whether to use camel-casing or underscores, then so be it.

Be logical

A lot of people will come to the conclusion that free electrons are hard to get along with and inflexible.  However, this is a person who hasn't learned to frame their arguments properly.  A lot of people tend to put things in emotional terms.  Emotional arguments have little impact on free electrons.

Remember how I said that free electrons hate not being listened to?  Responding to a free electron's arguments with emotion is equivalent to not listening to them.  However, you will find that a free electron is willing to listen to arguments about how their idea is the stupidest thing you've ever heard as long as you can present logical reasons why.  

Conversely, they're likely to not take others' feelings into consideration in discussing things.  Therefore, you need to understand that if they say something that comes off as insulting, they probably didn't mean it as such.  If this bothers you, it is helpful for you to point out when they're being rude as long as you do so calmly.

They may not realize how talented they are

Remember how I said that there are two personality types that can be free electrons?  Here is the area that differentiates them.  Masterminds tend to be very much aware of their talents, so this section doesn't really apply to them.  Architects usually aren't.  They assume that every programmer can understand what a monad is just by reading the wikipedia page on them.  Sometimes, you just need to get them to slow down for the programmers who don't spend their weekends writing compilers for fun.

They need direction sometimes

Free electrons tend to be focused on the big picture.  However, they're not very detail-oriented.  This means that they tend to be great at getting an overall framework for a solution set up.  They tend to not be very good at putting the finishing touches on things.  Thus, free electrons tend to be good at starting projects.

This is all well and good, but sometimes you need them to stick with something.  Typically, a free electron will want to move on to something else when they feel they've learned everything they can from the current project.  You can help to counteract this effect if you can point out other interesting things that are still left to do in the current project.

You have to be careful with this approach though.  If a free electron is forced to work on a project they find uninteresting, they will find a way to make it interesting.  You don't want to assign them to a little modification of one method just to find out that they've changed your piece of software's entire architecture.

...but most of the time you should just leave them alone

Free electrons are very autonomous individuals.  They'll probably dislike pair programming and hate micromanagers.  But that's fine because free electrons can do amazing things with little to no direction.  When teamwork is required, you should keep interactions with the free electron mostly at the high level.  If there's too much tedium involved, they'll probably turn very toxic very quickly.

Also bear in mind that free electrons tend to keep their thoughts to themselves.  In other words, if it seems like there are 10 levels of intricacy behind everything they say, it's because there is.  There are two things that can cause this:

 1. If your free electron is an Architect, they could very well assume that those 10 layers of complexity are obvious to you.
 2. They may just not feel like explaining it to you.

While number 2 makes free electrons sound like snobs, take a moment to think of the world from their perspective.  As stated, free electrons are ridiculously rare.  That means that they've spent their entire life trying to explain their way of thinking to people who will probably never be able to understand it because they just don't think the same way.

This leads them to unconsciously come to the conclusion that explaining things to people is hard and avoid it at all costs.  This makes getting the full story out of a free electron a bit like pulling teeth.  The best approach is to show some initiative.  Get them to talk about those subjects in normal conversation.  Chances are, they'll be more than happy to share if they feel you're genuinely interested in the subject and not just asking about it because it's your job.

They can't do it alone, no matter how much they claim otherwise

Free electrons can do amazing things that no other engineer can do.  But they have weaknesses that need to be balanced out.  This means they need good managers to help direct them and good engineers who can make up in the areas they lack.  The best free electrons are the ones who realize this.  Don't expect them to ever admit it to you though.
Loading mentions Retweet
Filed under  //   programming  

Comments [11]

The Rise of SYDNI, or YAGNI is Only About Problems, Not Solutions

I've got a new programming methodology to propose. I call it SYDNI
(Sometimes You Do Need It). It is a response to the problems that I
see with YAGNI. In fairness, I don't dislike YAGNI. In fact, I agree
with it 100% (well, maybe 95%). But to truly appreciate it, you need
a bit of context.

On YAGNI


 
I've almost started thinking of YAGNI almost as a recursive way of
thinking. That is to say that I've begun to think of YAGNI as being
something that uses itself to implement itself. Allow me to explain.

What is YAGNI?


 
YAGNI stands for "you ain't gonna need it." I don't want to make this post
an in-depth discussion of what YAGNI actually is, so click the
Wikipedia link if you aren't familiar with YAGNI. The important thing
to take away from reading about YAGNI is that it's saying that you
shouldn't implement functionality if you don't need it.

What YAGNI ISN'T


 
YAGNI sounds like a pretty straightforward way of thinking. And in a
lot of ways it is. But it's more nuanced than one may think at first.
 The "recursive" element of YAGNI that I speak of above is that YAGNI
(in my opinion) is a very specific solution to a very specific
problem, and that problem is over-engineering.
 
And YAGNI does its job well (especially in the context of Test Driven
Development). I tend to find myself throwing out a lot less code when
using YAGNI.
 
A lot of people take YAGNI to mean that the simplest solution is
always the best. That isn't the case. Or at a very minimum, that
shouldn't be the case. There's a key thing about simplicity
that should be understood: it's defined by the problem, not the
solution. This is key to understanding why YAGNI is so useful. Once
you've gotten to the point of choosing a solution, YAGNI is no help to
you. Thus, you have to use YAGNI to choose problems, not solutions.

You're not in school anymore


 
In school, things are always so simple. You're assigned a problem.
And you're given a grade based on how well you solved that problem.
The real world is more complex.
 
You see, people too often forget that software developers don't just
define solutions to problems. After all, aren't all feature requests
nothing more than a statement of a problem? And isn't choosing
software features a decision about what problems you will solve?
 
However, once you've chosen a problem to solve, there's still the
issue of how to solve it.

Sometimes You Do Need It


 
In solving a problem, YAGNI's usefulness starts to fade. It does have
some importance. You do have to make sure your solution is solving
the problem you set out to solve. However, beyond that, YAGNI just
doesn't apply. In fact, it is likely harmful. That's where SYDNI
comes in. Although SYDNI's name is something of a jab at YAGNI, the
principle itself isn't. Instead, SYDNI can be thought of as a
complement to YAGNI. A yin to YAGNI's yang (alliteration for the
win).
 
Oftentimes, thoughts may enter your head that start with something
like "we'll never need..." or "this will never have to...". This kind
of thinking is helpful when choosing the problem to solve. However,
it's destructive when choosing a solution. In a couple of years,
there is only one thing that will be certain about the software you're
writing: it will be different. And it will be different in ways you
can't have predicted or imagined. If you're using YAGNI
appropriately, you're choosing the easiest problems to solve.
However, at least a few of these problems come out of left field.
 
Therefore, I would put SYDNI this way: ideally, a piece of software
will be no more simple or complex than the problem it is trying to
solve. Therefore, there is danger not only in solutions that are
overly complicated, but there is also danger in solutions that are
overly simple.
 
This leads to another conclusion: if SYDNI is followed appropriately,
the complexity of your source code is a direct measure of how complex
the problems it is solving are. The reverse is true as well. The
complexity of the problems you're solving is a direct measure of how
complex your source code will be.

But I don't live in an ideal world!


 
The key hole in SYDNI is the word "ideally". Unfortunately, some
problems just don't have perfectly compatible solutions. Therefore, a
key decision to be made is whether it is better to err on the side of
over-engineering or under-engineering a solution. We are now delving
into the realm of many disputes between programmers. Many people
(mis)educated on the arts of YAGNI will say that it is always better
to tend towards under-engineering. If this were true, YAGNI wouldn't
be as useful to as many people as it has been.
 
Even more unfortunately, there is no "one size fits all" answer of
whether it is better to over-engineer or under-engineer. It is highly
situational and care must be taken to arrive at the appropriate
solution. If you don't believe me, consider the following two
questions:

  1. Which life support machine would you rather be hooked up to?
    •  A machine whose software developers always did the simplest thing possible 
    •  A machine whose software developers went out of their way to anticipate possible problems and planned for each of them 
  2. Which one-page web app do you feel would be easiest to maintain?
    • An application that is implemented as two or three source files and a few database tables 
    • An application with a highly normalized database, highly modular source, and great flexibility 

 

I should hope that the answer to number 1 is obvious. And why it is
the correct answer should also be obvious: if you missed a particular
contingency, people can die. Thus, it makes sense to err on the side
of over-engineering.
 
But number 2 is a little bit less obvious (and maybe more debatable).
However, I would err on the side of under-engineering. After all, no
matter what changes come up, a one-page web app is still a one-page
web app. The worst case is that the app would be rewritten from
scratch. That's not to say that you need to throw caution into the
wind and ignore normal good practice. Rather, it's saying that it's
not really a good idea to stress much over how maintainable that
application is.
 
Therefore, when deciding on a solution, there are two things that need
to be decided upon beforehand:
 
 1. How complex the problem is.
 2. Whether under-engineering is more harmful than over-engineering.
 
Once you get those two things squared away, it should be easy to get
an idea of how complex the solution should be.

Loading mentions Retweet
Filed under  //   agile   programming   sydni  

Comments [1]

About

Just another random geek. Read my old blog at http://jasonmbaker.wordpress.com/

My resume: http://careers.stackoverflow.com/jasonbaker