

Ask YC: The way hackers plan software - Novash

Company's willing to refactor heavily some main software of ours. We want to port all Delphi code to .NET so we can abandon a lot of legacy code. We've been planing said new software (suposed to do the same the actual does) for nearly two weeks already. Every module we cross is like trying to find the cure for cancer, and right now, I left the meeting because the main module of the project is being fully rewritten since it is prone to failure in some expected error condition and I don't want to have anythind to do with the mess they are designing (we work with hardware that wears out after a while and starts malfunctioning). Sorry about the whole rambling. My question is kind of simple. Do you start planing by the most complicated module to the simplest one, or the opposite? How do you design / plan your softwares at all?
======
jey
"Rewrite the whole system" is generally a BAD idea. You might want to have one
or two senior guys go and prototype the core parts of the new .NET version.
You can then add resources to the new one as it progresses. In a lot of cases
the development of the new one can overtake the developed-in-parallel old one
if it's done well, since they don't have to work with all the overhead of the
old legacy junk.

And if the new development project fails, oh well, you only sunk a few man-
months into the failed project. The sunk cost is smaller, so it's easier to
abandon.

------
jklubnik
Treating the old application as the spec for the new one is usually not a good
idea. Define the problem(s) the new application is trying to solve instead of
trying to copy the behavior of the old application. This is important for both
developers and users. (<http://www.chadfowler.com/2006/12/28/software-as-
spec>)

I like tackling the tougher parts first as assumptions usually conflict with
the real world and the design will change once you start building and testing.

------
Novash
Thank you for the feedbacks. I shall show it to my teammates. Do everyone here
hate meetings as much as I do?

~~~
asmosoinio
Sure, and this is good stuff about meetings: "Meetings are toxic":

<http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php>

------
DanielBMarkham
You design top-down, you code bottom-up, and you manage high-risk/first -- and
if you do it right, you code circles around anybody else, whether it's a big
or little project.

There's a longer answer, but it can run into several books worth of material.
That was about as terse as I could make it. I could provide an example if
you're interested.

~~~
akkartik
Yes please.

~~~
DanielBMarkham
Designing a computer system (and that means everything but the coding) is
constructing an intermediate vocabulary and language such that, when things
change, your intermediate language can already express the new conditions. Now
you can do that with functional code and a DSL, or you can do that with OOP
and a class model. Since you're going to .NET, let's assume OOP.

You've got two things to do before coding: analysis and design. Analysis is
understanding and creating that language I spoke about. Design is implementing
a solution with that new language inside a certain environment. Coding is
actually detailed design -- it's the same thing. In OOP you (generally) move
smoothly from talking to the users about their world to coding the computer.
In greenfield programming there are no major jumps like you would have with
waterfall. The goal of all of this A&D is to get classes, code units, tables
-- big hunks of stuff that will organize your code. Small systems you should
be able to burn through A&D in days or hours. Big systems can take much
longer.

Now there's all kinds of tricks to making good languages, er, object graphs.
Too much to go into here. Just remember that the purpose of OOP is that when
the customer says "But I'd like that green if the bank account balance is over
$200" that you should be looking to tweak something regarding the class
BankAccount and the member "Balance" -- the customer's language is your
language. This is what makes OOP rule large development work.

Now that's the 5-cent version of OOP. As for "What to do, when" it's real
simple -- do the stuff the team worries about. Having said that, it's
perfectly fine to use a "recipe book" like RUP, MSF, Agile, etc to help you
remember stuff you should be worrying about. In general, just like in coding
where you move from talking to the folks to making the code happen, you should
be thinking of "stuff to worry about" starting with business concepts "Do we
know what they want? Are they going to pay for it? Do we have access to the
key players?" Then you move towards technical concepts like "Are we sure a
relational database is going to handle this load?" or "There's no way the user
is going to wait more than 5 seconds at his browser" But there's no rule --
you can have killer business risks later in the project and you can have
killer technical risks earlier. The trick is to be constantly moving from big,
fuzzy, general, business-type worries to little, clear, specific, technical-
type worries. If you get your "conceptual cone" working in a project --
designing and managing from big concepts down to little concepts -- it's like
riding downhill on a greased rail.

I've probably proven myself a complete idiot for trying to take on such a huge
topic in a blog post, but there's a lot of "noise" on this subject: the core
principles are not supposed to be rocket science.

~~~
greendestiny
I think that's a great description of the process. I would make the point that
designing on customer language in OOP is one of those things experienced
programmers shy away from. The next paragraph about "What to do, when" is a
much better source of OOP design. Just to take the example of account balance,
in looking at business-type worries it would probably become clear that
transactional integrity is a big deal in this kind of software, so you'd want
to clearly separate out queries on the balance and modifications to the
balance and restrict access to the functions. These sorts of pressures, along
with technical pressures much more clearly describe the design parameters.

------
Tichy
You have read the appropiate joelonsoftware articles, I suppose? I just found
this one, for example:
<http://www.joelonsoftware.com/articles/fog0000000069.html> (might be good
reading for your manager, too).

I think the modern way would be to not rewrite from scratch, but to refactor
module by module. Presumably with .Net you can find a way to use your old code
as a .Net component? Then you could just replace components one by one...

If your new code is already looking like a mess, what is the point of the
rewrite? Except of course to secure your jobs because after the rewrite, there
will be another rewrite...

------
samb
this isn't the greatest answer, but it's what we do: we do what makes sense
based on the information available at the time. and then we adjust what we're
doing based on the information gained as the project goes on. sometimes core
mods have to be built first. sometimes we can grab low-hanging fruit first.

so, i'd have to say "it depends."

no one can answer this question for you, in my opinion. not without a full
understanding of the history and objectives. and even then, it'll be wrong and
have to be adjusted as the project unfolds.

so i suppose i agree with robmnl, but methodology alone isn't the cure.

------
izak30
I try to design my problems first, then my questions, (what data will I be
looking for, how is it related) [i.e. define the schema, it doesn't matter if
it's a single object or a database]; then my interfaces, and then I build all
my code as if every interface worked as planned.

Then I fix my interfaces, because things change in production; Then I fix my
other code.

I usually start coding in the middle, not all the detail things, and not the
giant core things, with some general drivers for the giant core things until
they are built.

------
damien
I'm curious as to what made Delphi "legacy code" and why it needs replacing?
Also, doesn't Delphi 2007 allow targeting to .NET? See:
<http://en.wikipedia.org/wiki/Borland_Delphi>

Be sure you aren't doing this rewrite for the wrong reasons.

------
robmnl
Try looking into agile methods, might be exactly what you need.

~~~
Novash
I wish. Can you send an email to my manager telling him this?

~~~
wozer
Be careful what you wish for:
[http://dilbert.com/comics/dilbert/archive/images/dilbert2666...](http://dilbert.com/comics/dilbert/archive/images/dilbert2666700071126.gif)

------
nextmoveone
id like to see peoples answers to this as well, cause i dont follow any form
or convention, i just start defining classes in the system

~~~
davidw
I too am of the 'exploratory hacking' persuasion. You just have to be ready to
throw bad stuff away with no mercy, and/or simply start over if it's not
working out.

~~~
abstractbill
This is the way I code too.

See <http://c2.com/xp/TheSourceCodeIsTheDesign.html> for some nice related
discussion.

