
Ask YC: Development-wise, what do you do that's unconventional and why? - ericb
I'm interested in how people are running against the herd and why.<p>A good example of what I mean would be HN's use of tables for layout--it's not trendy.<p>For myself, I am playing with stylesheet formatting so most things are on one line, which I find faster to get around, and easier to see more at once. Another example is I now rarely abbreviate in variable and function names. I've decided I waste more time remembering my abbreviations than I would spend typing the word.
======
iseff
For Openomy, one of the things that makes our project really exciting day-in
and day-out is that we went to a service based architecture early. We don't
have one single application for everything and we don't have one single
database for everything.

For instance, we have a user service (which controls accounts, sessions, etc
and has its own database), a metadata service (which controls what files we
know about, what tags they have, etc and has its own database), a file service
(which controls the actual binary data of the files and has its own database),
etc (we have a few others, but that gets the point across). They talk to each
other through REST -- though it could be anything, of course -- to get
anything done they might need.

This allows us to scale each service independently, which is great. I'm always
surprised at how long it takes folks to move to a SOA.

But, perhaps, the coolest part from an always-hungry-to-try-new-things
development team is that having a service based architecture means that we are
free from programming language constraints. As long as the language can speak
HTTP, we can try it out for a new service or a new client. There's nothing
like the feeling you get when mastering a new language. And there's no better
way to master a language than write something tens of thousands of people will
be using.

So, we have an old front-end built in C#/Mono, we have a couple Rails
services, a Java service, our new APIv2.0 (<http://api.openomy.com>) is
written in Haskell/HAppS (which I'm particularly proud of), and now we're
writing a client in Scala. And, besides that, we use Perl for some offline
scripting tasks.

I think it's pretty unconventional-- but it shouldn't be! I highly recommend
going this route.

~~~
bsaunder
I'm working on a variant of this SOA model using (don't laugh) IRC and JSON.
Pick your language, and hook-up.

------
nostrademons
Pencil & paper for a lot of the design & architecture work. I write a lot of
little notes to myself in a spiral-bound notebook.

Using immutable data structures. I've jiggered up some Python decorators to
handle the copying for me, so all my setters return a new object instead of
mutating the old one.

Writing code that's both Flash and JavaScript. A lot of our product is written
in the common subset of both languages, with a compatibility library to paper
over differences.

~~~
cousin_it
I design on paper a lot too. A new feature or big refactoring has to be
absolutely clear in my mind before I start coding.

ActionScript classes are syntax-incompatible with JavaScript, how did you
solve this? An AS to JS mini-translator seems to be the simplest way, no?

~~~
nostrademons
I don't use ActionScript classes. Everything's done with closures and literal
objects. Can't even use prototypes; MTASC doesn't allow standalone functions
or prototype declarations (instead _requiring_ that everything live inside a
class), so that falls outside the common subset. We namespace things the way
it's done in JavaScript, with objects serving as namespaces, so there's a
notion of libraries that're imported at compile time. My Scheme experience
certainly comes in handy.

I haven't ruled out doing a mini-translator; this is very obviously a hack,
and if the common codebase grows much larger we'll probably appreciate it.
(We've also considered rewriting the whole thing in pure Flash, but there're
certain user benefits that the dual-language architecture gives us that we're
not quite ready to give up.) This approach is "good enough" for now though, so
we're hoping that it'll get us to an initial launch, and then we can decide
whether it needs a rewrite based on what users want to do with it.

------
benl
I'm not sure whether any of these are anti-trendy or not, but here are a few
things I found myself doing in a project I've been working on recently:

* It's an online bookmarking system, and I didn't add tagging. I found that the UI step to add tags was a bit of a usability burden, and that I never actually used them to find stuff again anyway.

* I wrote it in Perl. Definitely not trendy, but it's fast, dynamic and (with mod_perl) stupidly easy to deploy.

* I rolled my own JavaScript libraries and wrestled with cross-browser issues rather than using jQuery, prototype, or some such. Why? To learn the nitty-gritty details of DOM manipulation and browser compatibility.

* I de-normalised the database from the start. Why? Because it enabled me to build a simple, light and fast object-oriented table wrapper without the overhead of dealing with associations, joins, and so forth. For any structure that does require a table join, I use database views to make it look like it's a simple table to the application.

------
mronge
For my desktop application I've decided to spawn processes rather than threads
even though the trend these days is to use processes.

It separates the engine of the app from the GUI, and the interface between is
well defined. I use txt + UNIX Pipes to communicate.

Also, any stability issues and memory leaks don't effect the entire app and I
get to avoid all the weird concurrency issues of threads.

------
sah
I mix tables and divs in my layout. I use whichever is easiest and works best
on the most browsers. In general, I regard HTML/CSS as bytecode for browsers,
not a programming language that I should write readable code in, and web
standards as something I hope browsers will comply with, not web sites.
Sometimes I even abandon templates in favor of graphics-library-style HTML
generation.

------
crystalarchives
I'll have to second not using an IDE; I use (g)vi(m) instead.

It forces me to understand each step of the development process, reduces the
overhead of any machine I work on, and allows me to work on pretty much any
server, anywhere, using just Putty/Terminal.

Interestingly, I also try to minimize the amount of customization I do,
sticking instead with the defaults so I can easily work in new environments.
I'm not sure if that's unconventional though.

------
brlewis
Not long ago I would have said using a Lisp dialect for web development, but
now I think that might actually be trendy.

~~~
SwellJoe
It's still very much in the minority. You're just running with an oddball
crowd here at HN. If you look at projects being released and sites being
launched, PHP is still the most popular by an order of magnitude, with Ruby
and Python gaining. So, don't worry, you're still a lisp weenie hanging out
with the long-haired weirdos and art fags at lunch.

~~~
brlewis
OK. In that context, the unconventional thing I've done is to make an actual
functional site used by people who don't have CS degrees. In fact, the target
market is adults who have a life. Like me! I do stuff, you know. I'm about to
go do stuff now. (Upgrade tinymce.)

~~~
michaelneale
That is very unconventional indeed ;)

------
pg
I simultaneously munge the language and the application written in it.

~~~
scott_s
I discovered today that's actually an established practice: <http://lambda-
the-ultimate.org/node/2711>. I haven't read any of the papers yet, but looking
at the abstract of "Language Oriented Programming" by M. P. Ward, there does
seem to be a difference between his idea and your approach with Arc and your
other projects.

In the abstract, Ward defines Language Oriented Programming as defining a
formal description of the language to develop the type of application in
question, and then write the application in that language, and implement the
compiler using existing tools.

The problem I see with this approach is that it's rare to know ahead of time
what the ideal language for an application should look like. I don't think
you're really going to know until you try to develop it. That's how the Arc
approach differs. Particularly when you're already working in a language with
rich meta-programming/code generation capabilities, I don't think there's any
reason to have a strict separation of the phases. Even if you're not using a
language with innate code generation, it's still possible to iterate back and
forth between writing the application and changing the language/compiler

Keep in mind I haven't read the whole paper yet, or any of the related work,
so the methodology might not be as strict as I've presented.

~~~
stcredzero
The common practice in Smalltalk is to just extend Smalltalk so that it
becomes a powerful domain specific language for your application. Most
everything in Smalltalk is just an ordinary message send (procedure call) so
any good programming where you Don't Repeat Yourself ends up being a domain
specific language.

~~~
scott_s
Is that where Ruby got this tendency from? I haven't used Ruby yet, but I see
this style of development talked about in conjunction with Ruby.

------
mixmax
Nothing - I think the key is to minimise risk, and find the few areas where
you can actually add value. My value adding is in usability and design - the
actual code is pretty simple. So I see no need to take risks code-wise and
stick to tried-and-true (boring?) programming paradigms.

~~~
paulgb
Agreed. Blub can do everything I need anyway.

------
noonespecial
I use perl as pseudocode, especially when I have to target multiple
languages/platforms.

Its stupidly easy to hack together prototypes of functions to test out data
structures and algorithms just using perl and the command line. This helps me
think more about the structure of the program and less about the syntax of a
specific language, especially languages that I'm weaker in.

Once its working right and thought through, I'll use the perl "pseudocode" as
a guide to code in the target language.

------
jdvolz
I'm in favor of the speed of flat files. I have two Windows desktop
applications (one for sale, one freeware) that both were converted from using
a database to using a simple flat file. It was easier to program and much
easier to distribute. One of the programs has a search functionality - it's
just the normal linear text search. Even with all the data I have in the
program it's instantaneous.

------
SwellJoe
I've started tinkering with the idea of using JSON for RPC calls, particularly
across languages. It's lighter than CORBA, XML-RPC, SOAP, etc. and well-
supported by all of the languages I like and use. One has to formalize some
sort of standard function call interface, but since JSON is relatively limited
and similar to the data structures one could pass as arguments in Perl or Ruby
or Python, that's pretty easy and natural. And I hate XML.

I use Perl (which, given the number of others here mentioning Perl, seems to
not be so unconventional after all). Partly because our codebase is 450kLoC,
or so, and almost all Perl. Won't be rewriting that anytime soon. Perl is also
very comfortable for system administration tasks. Moreso, in my experience,
than Python.

I think a lot more than I code. If I write more than a dozen or so lines a
day, it's a heavy day. I am mainly maintaining and extending existing
software...so it's often just wrapping my head around the existing API and
code. But even when starting from scratch on something, I take a long time to
start actually coding, and only occasionally have a blast of productivity
where I push out a couple hundred lines in a single stretch. This is somewhat
bug-like, but I've never really been able to change. Luckily, as I've gotten
better at the tools I use (Perl, JavaScript, and shell, mostly) those few
lines of code tend to actually accomplish quite a lot--and the resulting code
is usually nice to maintain because it is very short. So, the work does get
done...but when I look at my co-founders output, I always feel tiny. He pumps
out hundreds, and sometimes thousands, of lines per week...and they all work
really well and are often as concise as what I would have come up with (though
not always...he sometimes "powers through" and tightens it up later when it
becomes a problem, which is a skill I often wish I had).

------
crux_
When I'm doing algorithmic work, I rewrite rather than refactor. Perhaps it's
just me as a programmer, but it takes me three or four rewrites before complex
and nasty algorithms begin to appear simple.

Also WRT abbreviations and again in algorithmic code: I love to use one-letter
variables for 'working' variables. It forces me to reread what I've written
and really understand what's going on, rather than take shortcuts based on
what a variable name might imply.

Business logic "if the account balance is below $100 send a warning email"
code need not apply ... for that stuff I just wade through same as anyone
else, although I'm more apt to write code that writes code if I'm faced with a
particularly high pile of the stuff.

------
hernan7
Generate Java boilerplate using shell scripts -- not sure if that was included
in the list of new sins the Vatican put out last week.

------
jcromartie
I never code in a mega-syntax language (Perl, C++, C#, Java 5) if I have the
choice. I feel that I'm lighter on my feet and able to move between
environments better by sticking with languages that have more terse syntaxes.

------
bayareaguy
It looks like people have already picked the low-hanging fruit here, so here
are a few things not yet mentioned I try to do that I don't see others do
often:

I use tools like Libero[1] to express service logic directly as a state
machine.

I generally try to build and maintain a simulator for whatever I'm working on
with tools like SimPy[2] and Spin[3].

I try and use Excel spreadsheets to build mock-up GUI's.

I try and make it so that all database access occurs behind service API's.
Before I have the basics worked out I don't even bother with an actual
database and instead just use memcached[4] and a file of initial data.

[1] - <http://legacy.imatix.com/html/libero>

[2] - <http://simpy.sourceforge.net/>

[3] - <http://spinroot.com/spin/whatispin.html>

[4] - <http://www.danga.com/memcached>

------
mattculbreth
Recently I've found myself writing out a tricky algorithm in comments at the
top of the function. Easy, bulleted English points about what this function is
doing. I then find that I can do the coding and simply make a quick comment
back to the bulleted list. "# 1. Load users into dictionary", etc.

------
pius
I guess something I do is using bleeding edge frameworks and libraries to
start projects if I think it'll give me an advantage. I figure that they'll
stabilize (or I can help stabilize them) in time for the production release of
what ever I'm working on.

~~~
SwellJoe
I did that with ExtJS (starting way back when it was first announced as
YUIExt). I haven't been entirely happy with the manner in which it has
matured, as it has bloated into a somewhat intimidating Java Swing feeling
creature (which is both good and bad) that means the most comfortable way to
develop is without any HTML at all--everything is built in JavaScript and data
comes in via JSON. But now that I'm about to finish up the project that uses
it, it's turned out pretty awesome.

------
iamdave
Can't vouch for exactly how unconventional this is, but when I'm building a
website I go through and do all of the HTML first, then CSS. Some I've seen do
both at the same time, create a header, then make the CSS, navigation, then
CSS, little by little.

------
stcredzero
I work in a Smalltalk shop where we get around Smalltalk's lack of
Interfaces/Multiple Inheritance with State/Strategy objects. That's not so
unusual. What goes against the grain is our eschewing polymorphism in that one
situation, instead having case statements for the different object types. My
boss prefers that because he feels it's better from a code management
standpoint. The rest of us just quietly acknowledge to ourselves that it's not
real OO, and play along.

Surprisingly, it works well, probably because it discourages us from making
those things too complicated. The frameworks/APIs used by those objects have
to be clean.

------
wallflower
While looking at a co-worker's UI code the other day, I commented out loud to
him and our other cubicle dwellers that "I would have coded it very
defensively " and told him "that he took risks programming and that was _why_
he was more likely to _start_ _a_ _business_ _than_ _I_ (the conservative
programmer) _was_ (he's got an entrepreneurial long-term outlook).

Some of the things he was coding seemed relatively risky (e.g. relying on
binding to work flawlessly with a complex, deep nested model - we've had hard-
to-debug issues with ssome Flex UI-field binding in the past)

~~~
ericb
Bad, difficult-to-debug programming is not moving against the herd, it's
moving with it.

Are you implying poor programming makes one more likely to start a business?
That will float like a lead balloon here.

Am I misunderstanding your post, or feeding a troll, perhaps?

~~~
wallflower
My intention was not to imply that bad, difficult-to-debug programming makes
someone more likely to start a business.

The issues with Flex in the past with viewing/editing attributes on a complex
parent.child.subchild model are in the past (they fixed the issues). His code
was not "bad, difficult to debug" it was "risky" in the sense that Flex didn't
support it in a previous release.

When I told him that his code was risky, I said it with a half-serious tone
(e.g. half joking). Rereading the post indicates that the tone of the post and
the tone of the original comment never carried through. I apologize.

~~~
ericb
No worries, a lot is lost in typed communication.

~~~
tokipin
them's fightin' words

------
edw519
I do all my client-side prototyping in a technology that does not use a mouse,
graphics, or a browser. Once the basic functionality works perfectly, then I
port it over to javascript and add the rest of my interface.

~~~
ericb
I'll bite. What's the technology? Are you going to say paper? :-)

~~~
edw519
<http://www-306.ibm.com/software/data/u2/universe/>

~~~
bayareaguy
+1 for Pick

------
scott_s
Writing C++ code that's as functional as I think is reasonable; lots of
recursive function objects operating on containers, but with mutable data.

~~~
albertcardona
I have a similar approach for Java:

\- as functional as possible, using classes almost only as namespaces.

\- lots of little inner classes as data tuples.

\- lots of recursive functions filling in/trimming out containers.

\- the 'final' keyword is the best of the lot.

And no standard boiler-plate "patterns" for which the java language is sadly
know (and which make java code unreadable, unpleasant, and altogether a
horrible experience).

~~~
crux_
Why not take the jump and just use Scala? I have. :)

~~~
vikas5678
what editor are you using for scala? The eclipse plug barely does anything and
I am fed up of using the scala interpreter on emacs :(.

~~~
crux_
Sorry to say that I use emacs, so I can't help you too much. It occasionally
screws up indentation but otherwise stays out of my way.

(I'm far from an emacs power user -- also I don't use the interactive toplevel
much, and never from inside emacs; instead I throw that sort of thing in run-
once junit code in case it becomes a test suite.)

------
cousin_it
I consciously try to program like a newbie, moving ahead clumsily and
directly. Make it work, then make it small. Code is a bridge, it doesn't need
to look good, just get me across. What use is a beautiful bridge to nowhere?

------
patrickg-zill
Never MySQL ; Solaris instead of Linux ; AOLserver instead of Apache and *AMP
stack.

~~~
SwellJoe
I used AOLServer and OACS for Virtualmin's first website. I got over it.
<http://www.obsceneart.com/?p=6>

------
t0pj
Based on all of the comments submitted thus far, it seems that an uncommon
philosophy is actually quite common. :)

Can we not "rage against the herd" while running with the herd?

Does the direction in which we wish to go need be contrarian?

Am I making any sense whatsoever? :/

~~~
ericb
I see what you're saying, but there's a difference between being contrarian
for the sake of it and being so for a reason.

Having a good _why_ is the difference between Darwin and a Darwin-award
candidate. Sometimes a best practice is best, sometimes it's just a practice.

------
deltapoint
I ask questions on YC!

------
albertcardona
I use the shell as a development environment. In this world of SPE, Eclipse,
and XEmacs, developing C/python/Java/others in a shell with vim, grep, sed,
less, find, is starting to become unconventional.

I just cannot tolerate the mouse-clickiness of all mainstream IDEs, neither
the extreme use of the control+this+control+that of emacs.

My primary reason to get into vim was the promise of short key bindings, very
easy text editing/rewriting and no mouse. It fullfilled that promise: my
wrists have not hurt again ever.

~~~
davo11
>> my wrists have not hurt again ever.

Have you tried a trackball? if I use a mouse for a week or so my wrist starts
aching, with a trackball none of those problems.

~~~
albertcardona
Sorry, I blended together several issues:

* My wrists used to hurt a lot from bizarre keybindings that use the control key (I used to use emacs a lot), than from mouse usage. Remapping to the caps is no use (strains my left little finger and left upper side of the hand). Remapping to alt (or to the apple key, in a powerbook) helped a lot, but still too many control pushes.

* The mouse slows me down, way more than hurts my wrists.

* I use Blender a lot. Using the mouse for Blender is no problem regarding my wrists. The trick for me is: extend the arm to fully rest in the table, flat, so that the mouse ends up nearly behind the laptop.

------
mrfish
Use a text editor like JEdit to do my code because I hate eclipse and it's
overhead and I like the color coding and the fact that I can install it
anywhere.

~~~
kleevr
Me too! I'm trying to school myself in VI (gvim), but until I reach that
golden shore I'll be keeping a more intuitive editor handy.

edit: Heavy IDE's haven't paid off for me yet. (I like to be familiar with
every point of control in my environment. Hidden configurations have given me
more headaches and stress than my personality can afford.)

Devil's advocates could certainly say I just haven't spent enough time
learning IDEs.

I would respond with tangent rant about the virtue of owning ones means of
production which includes knowledge. Knowledge ownership seems more obtainable
when you must know how to do everything from the ground up.

~~~
mrtron
I used eclipse in a corporate environment and I understand its value.

a) Everything in one tool. Your servers can be right there, you have your
code, your repository is directly connected, etc. b) It is actually is pretty
good. If it wasn't so bloated I would use it. c) It is easy to train people to
use eclipse, debug in eclipse, its all visual. d) Loads of plugins, again all
in one tool.

Cons would be it commonly eats up over a gig of ram. It is slow. An expert in
emacs can probably do most tasks quicker than an expert in eclipse.

~~~
kleevr
You know what, it's high time I give emacs a fair shot, before I become to
indoctrinated.

------
earle
i buck the trend by building sites that effectively work.

