Ask YC: The way hackers plan software
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?
19 comments
"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.
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.
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.
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.
Thank you for the feedbacks. I shall show it to my teammates. Do everyone here hate meetings as much as I do?
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
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.
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.
Yes please.
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.
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.
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.
Thanks for taking the time to write that, Daniel. I just learned a thing or two reading it.
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...
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...
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.
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.
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.
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.
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.
Be sure you aren't doing this rewrite for the wrong reasons.
Try looking into agile methods, might be exactly what you need.
I wish. Can you send an email to my manager telling him this?
Be careful what you wish for:
http://dilbert.com/comics/dilbert/archive/images/dilbert2666...
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
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.
This is the way I code too.
See http://c2.com/xp/TheSourceCodeIsTheDesign.html for some nice related discussion.
See http://c2.com/xp/TheSourceCodeIsTheDesign.html for some nice related discussion.