

Save your Cleverness - DanielRibeiro
http://tirania.org/blog/archive/2011/Mar-29.html

======
ErrantX
I tend to agree with the sentiment here; I like to play around with new
ideas/stuff/software/architecture, and constantly look for way to make use of
it day-to-day.

But if I've decided to take on a new project it's best to default to my usual
stack (PHP (Kohana), MySQL Nginx) and rattle out the basics. It makes a lot of
sense to solve a "hard problem" in an environment that is second nature to
you; too many projects flounder because as well as the project you're also
dealing with a new architecture.

(this is why I always dislike this idea of using a project to learn an
language... it never works out)

Actually, as an example of this, I've been working on a new project at work
recently which uses PHP/MySQL - but I've been looking into packaging it as a
VM appliance, and the considerations/work related to that has put me about a
week behind getting the actual project done.

~~~
eande
>(this is why I always dislike this idea of using a project to learn an
language... it never works out)

How than do you learn a language?

~~~
ErrantX
Small tasks, the tutorials. All sorts of ways.

But if you're learning Ruby, writing a Rails app is not necessarily a good way
to start. And if you are learning Rails writing a full on project as you're
introduction is going to flounder.

~~~
bad_user
It depends - Rails has so many conventions used (magic behavior) that, while
useful, you have to learn them all and even how to override that behavior,
before being able to tackle anything else other than simple blogging software;
although the learning experience is enjoyable.

On the other hand Django is an (arguably) thin layer on top of Python. You can
start from the URLs specifications and how to construct a simple HttpResponse
object. And that's all you need to know and how tutorials teach it -- for
everything else you can rely on your previously learned skills, while learning
shortcuts on the way.

For another perspective -- Rails learning is top-down, while Django is bottom-
up.

------
methodin
Telling people to take shortcuts and write spaghetti code is a terrible idea.
I'd venture to say the people nodding their heads have never had to deal with
a million line code base with spaghetti code, duplication (50%), terrible
architecture and no unit tests. How do you think it got that way? "We got a
new client! We need X functionality right now! You want to re-architect? We
don't have the time!" etc... etc... If your product is never successful its a
moot point either way. If it is, you better damn well hope you have free time
to both expand your product and re-architect it.

I'd much rather see a sentiment of "never sacrifice architecture for
functionality but never let architecture drive your features."

~~~
coliveira
The more I learn about entrepreneurship, the more I come to realize that
writing the spaghetti is the way to go. Writing software quickly is much more
important than writing it well. Of course, when you have a product that makes
money you'll have to rewrite it, but by then you will have money to pay for
developers... How do you think Facebook was created?

~~~
generalk
_> Writing software quickly is much more important than writing it well._

I would say that _releasing_ software is more important than continually
delaying for amorphous "quality" concerns, but this is backwards. You want to
write quality software. I've been on several teams that valued speed over
quality, and in the end we always end up with a sad, fragile bit of software
that's hell to maintain or add features to.

 _> Of course, when you have a product that makes money you'll have to rewrite
it, but by then you will have money to pay for developers..._

Again, having been part of teams that operated this way: _later never comes._
Paying customers means people relying on your software. You can't just stop
working on it to rewrite from scratch, and their bugs/issues/feature requests
are _far_ more important than _refactoring_ (which they'll never notice.)

If you ever want good software, make it good from the start.

~~~
coliveira
I really hate spaghetti code, but that is because I'm a developer. The sad
truth is that the reason a lot of developers like you are hired to work on
this kind of team is that somebody was smart enough to release software
quickly and make a business out of it...

------
bad_user
I totally agree with the sentiment, and I have always valued Miguel's work and
opinions.

But this man started to work on a .NET clone as he was fed up with working in
C for Evolution -- if building your own compiler when nothing else matches
your needs and desires is not the ultimate form of yak-shaving, I don't know
what is :-)

~~~
Hoff
That's a yak-null; a first-order yak-shave.

Building your own hardware to build your own assembler to create your compiler
to build your own OS to allow you to build your own CAD system to create your
own board layout and test tools to build your own processor to create an
assembler to...

There's always room for a higher-order yak.

~~~
bitwize
_Building your own hardware to build your own assembler to create your
compiler to build your own OS to allow you to build your own CAD system to
create your own board layout and test tools to build your own processor to
create an assembler to..._

You mean like Chuck Moore, the Chuck Norris of computing?

~~~
1337p337
You may have it backwards: Chuck Moore doesn't compute. He tells electrons
where to go, and they take orders. Inside every computer built by Chuck Moore,
there is only another computer built by Chuck Moore. Chuck Moore once built a
zero-instruction chip that always produced the correct answer. According to a
doctor that wished to remain anonymous, Chuck Moore has only two internal
organs: a whiskey processing unit, and a NAND gate. Chuck Moore once traveled
back in time just to convince Alan Turing that his computer didn't need any
I/O devices besides a tape reader.

SCNR

------
jonmc12
Author is right on. Reminded me of
<http://news.ycombinator.com/item?id=2329105> \- drawing the line between
work, play and deliberate learning.

------
cmullaparthi
How do people deal with staff who are quite clever, but write very complex
code? I know a person who is a very good engineer in that he understands the
underlying principles, but writes horribly complicated code. I'm trying to get
him to write simpler code, but haven't succeeded so far.

~~~
megrimlock
Start by talking to them about how you think they are really good at solving
problems -- and how one of the challenges you hope they can solve is producing
work that others on the team can understand and extend. They may need to first
hear you acknowledge that they are talented and that you admire their work --
and then that you wish their work was more accessible to the rest of the team.
The idea is that most good engineers will want to produce work that others can
understand and appreciate. You just need to make it clear that you consider
that part of the domain of problems they should be keeping in mind.

If this goes well, you might also want to acknowledge that this may mean
taking less sophisticated, less forward-looking approaches. A lot of over-
engineering is like over-training a model to historical data, assuming the
future will be exactly like the past. Anyone who's worked on software for very
long will be acutely aware that needs change over time.

~~~
cmullaparthi
Thanks all for the comments. I've tried all those approaches, but failed so
far. I'll keep trying.

------
cosgroveb
Miguel plugs "Why Programs Fail." Does anyone here second that recommendation
or have an alternative? I'm about to buy it, I think.

------
rickmb
Okay, I agree with the basic principle.

But why is it every time somebody writes a piece about focusing on the "stuff
that really matters", whether it's the user experience, or actually shipping
stuff, it always sounds to me like an excuse for taking unnecessary shortcuts?
Since when is dependency injection a "fad"? What the f __* is wrong with
writing unit tests?

Or in other words, what's wrong with building half-decent code the first time
around? It doesn't take much more time and it makes refactoring afterwards so
much easier. Using very common basic best practices when coding has nothing to
do with over-architecting or trying to be clever.

~~~
coliveira
I believe all of that is fine, the problem is spending too much time on it.
For example, writing comprehensive unit test may be not much better than
having just a few, because there is no way to test for every possible bug.
Also, in some situations it is better to have code with a few bugs than no
code at all.

~~~
okaramian
Unit testing is more about documenting the expected behavior of software, not
necessarily to test every possible contingency.

If you want to write dirty code on an initial run, and refactor later unit
tests will help out a whole lot.

------
csomar
_Take the shortcut. Build the product. And if later, it turns out you made a
design mistake, refactor the code. But at least you will have a product that
your users love._

This doesn't seem to be working with me. When you re-factor a part of your
code, you are probably doing it for optimization. When your architecture is
broken and you are going dark, I don't think you can still re-factor your
whole code base and keep your customers happy. (Deadlines, bugs, downtimes,
costs...).

