3 ms·

Ask YC: The way hackers plan software

15 points by Novash 19y ago

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?

robmnl 19y ago
Try looking into agile methods, might be exactly what you need.
- Novash 19y ago
  I wish. Can you send an email to my manager telling him this?
  - wozer 19y ago
    Be careful what you wish for: http://dilbert.com/comics/dilbert/archive/images/dilbert2666700071126.gif http://dilbert.com/comics/dilbert/archive/images/dilbert2666...
nextmoveone 19y ago
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 19y ago
  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 19y ago
    This is the way I code too. See http://c2.com/xp/TheSourceCodeIsTheDesign.html http://c2.com/xp/TheSourceCodeIsTheDesign.html for some nice related discussion.
DanielBMarkham 19y ago
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 19y ago
  Yes please.
  - DanielBMarkham 19y ago
    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.
samb 19y ago
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.
jklubnik 19y ago
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 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.
izak30 19y ago
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.
jey 19y ago
"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.
Novash 19y ago
Thank you for the feedbacks. I shall show it to my teammates. Do everyone here hate meetings as much as I do?
- asmosoinio 19y ago
  Sure, and this is good stuff about meetings: "Meetings are toxic": http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php
Tichy 19y ago
You have read the appropiate joelonsoftware articles, I suppose? I just found this one, for example: http://www.joelonsoftware.com/articles/fog0000000069.html 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...
damien 19y ago
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 http://en.wikipedia.org/wiki/Borland_Delphi Be sure you aren't doing this rewrite for the wrong reasons.

15 points by Novash 19y ago

robmnl 19y ago

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

Novash 19y ago
I wish. Can you send an email to my manager telling him this?
- wozer 19y ago
  Be careful what you wish for: http://dilbert.com/comics/dilbert/archive/images/dilbert2666700071126.gif http://dilbert.com/comics/dilbert/archive/images/dilbert2666...

nextmoveone 19y ago

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 19y ago
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 19y ago
  This is the way I code too. See http://c2.com/xp/TheSourceCodeIsTheDesign.html http://c2.com/xp/TheSourceCodeIsTheDesign.html for some nice related discussion.

DanielBMarkham 19y ago

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 19y ago
Yes please.
- DanielBMarkham 19y ago
  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.

samb 19y ago

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.

jklubnik 19y ago

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 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.

izak30 19y ago

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.

jey 19y ago

"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.

Novash 19y ago

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

asmosoinio 19y ago
Sure, and this is good stuff about meetings: "Meetings are toxic": http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php http://gettingreal.37signals.com/ch07_Meetings_Are_Toxic.php

Tichy 19y ago

You have read the appropiate joelonsoftware articles, I suppose? I just found this one, for example: http://www.joelonsoftware.com/articles/fog0000000069.html 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...

damien 19y ago

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 http://en.wikipedia.org/wiki/Borland_Delphi Be sure you aren't doing this rewrite for the wrong reasons.