15

I learned at school as well as I read everywhere else that a good development methodology needs conception and design before coding properly.

That is not a new information even for a beginner programmer. However, I wonder if this a good advice because since I started developing in several programming languages I never succeeded to design and conceive everything since the start.

I mean, I always melted design, conception and programming. Am I the worst developer in the world, or is the idea we learn at school just an old meaningless religious dogma?

How can we even conceive and design something we never experienced and programmed before? Is not that ridiculous? Does not programming lead the conception and design instead?

  • 2
    possible duplicate of [Develop fast and buggy, then correct errors or be slow, careful for each line of code?](http://programmers.stackexchange.com/questions/99980/develop-fast-and-buggy-then-correct-errors-or-be-slow-careful-for-each-line-of) (see also "linked" questions there - [Does craftsmanship pay off?](http://programmers.stackexchange.com/questions/82159/does-craftsmanship-pay-off) etc) – gnat May 22 '14 at 16:25
  • @gnat the link you have given here may be an answer for one aspect of my question. I do not think this is a duplicate question. –  May 22 '14 at 16:28
  • http://meta.stackexchange.com/questions/194476/someone-flagged-my-question-as-already-answered-but-its-not – gnat May 22 '14 at 16:28
  • 13
    No plan has ever survived contact with the enemy, but that doesn’t mean you shouldn’t have one. Start with a plan but don’t be afraid to modify it later – Richard Tingle May 22 '14 at 17:22
  • 2
    The only time you truly and fully understand a problem is after you've solved it, so it only makes sense that once you understand the problem, you can solve it better. But you need to go through the exercise of discovery to really understand the problem. – Matt Klinker May 22 '14 at 18:14
  • "There are many different styles of composition. I characterize them always as Mozart versus Beethoven. When Mozart began to write at that time he had the composition ready in his mind. He wrote the manuscript and it was 'aus einem Guss' (casted as one). And it was also written very beautiful. Beethoven was an indecisive and a tinkerer and wrote down before he had the composition ready and plastered parts over to change them." --Edsger Dijkstra – Doval May 22 '14 at 20:59
  • Only common sense and working prototypes help to do something worthwhile. Do not get caught into endless design sessions and talks about methodology of programming, metrics etc - better show what do you mean by launching prototype. However it is worth to read someone else code and design docs of well-designed system you can find in your field. – lowtech May 22 '14 at 22:08
  • duplicate of [What should be first - functionality or design?](http://programmers.stackexchange.com/questions/39499/what-should-be-first-functionality-or-design) – gnat May 23 '14 at 03:37
  • @mklinker: You've changed my point of view of the world!!!! it was deep man! – Magno C May 23 '14 at 13:13

8 Answers8

30

It is absolutely true. The larger and more complex the requirement, the more true this is.

For a small console app to calculate the Fibonacci sequence, you may not need more than a few minutes of thinking about how to structure the algorithm and the UI (which, yes, could simply be stdin and stdout).

But how about a real-time trading platform expected to do millions of transactions a second, distributed globally and that requires 99.9999 of uptime and 100% of correctness? Would you just jump into coding that?

There are lots of other options between these two extremes.

Take a look at project Euler. Solve some problems, in the presented sequence. You will find out that in order to solve some of the problems in reasonable time, you need to actually think before jumping into code.

If you do not need to take time to think and design your program before starting to code, you are either working on trivial things or missing something larger.

I never succeeded to design and conceive everything since the start

No one does for anything but the most trivial of problems. Again, the larger and more complex the project, the more true this is - designs will be have mistakes, things that are overlooked etc...

The art is in designing in high level first, seeing if the large pieces fit. Then get a list of priorities - starting to work on the most crucial / infrastructure first. Then we go and break down the larger pieces to smaller ones, making sure each larger piece is composed of pieces that make sense.

This takes time and effort - and may not be complete or fully correct at the beginning.

But this is why it is called soft-ware and not hard-ware. It is malleable and can be changed.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
Oded
  • 53,326
  • 19
  • 166
  • 181
  • 4
    Great answer. Note that, although software _is_ malleable (indeed, this is one of the amazing and unique things about it), modifications aren't _free_. The more tightly coupled and incoherent a software system is, the more difficult and expensive it will be to modify it. The upshot is that part of what goes into software design should be _the ability to change in the future_, if one wishes to take advantage of software's malleability. – voithos May 22 '14 at 22:10
9

I learnt at school as well as I read everywhere else that a good development methodology needs conception and design before coding properly.

This is true.

However, I wonder if this a good advice because since I started developing in several programming languages I never succeeded to design and conceive everything since the start.

And there's your problem.

For most non-trivial problems, you're going to need to do some thinking to figure out how things are going to work - how things are going to fit together. Paradoxically, for most non-trivial problems, there's no way you'll be able to plan everything out. There's just too much unknown for you to account for, too much change that will occur during development. Agile has gained the traction it has because it accepts this second half of the deal: people are not omniscient and change is constant.

So it's certainly true that you need to do design ahead of time, but it's also true that it's impossible to only design ahead of time.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
6

I think the answer has to be: Plan as much as you can, but not more than that.

Few people would speak against the virtues of planning, but the debate mostly overlooks an important aspect. Planning only works as far as you have the skill to make a good plan, that skill tend to come with experience. If you don't have a lot of experience any plan you draw up will likely have a fair amount problems, this means that in order to make a product that isn't a total disaster the plan will have to be revised heavily during development, if the plan is detailed then this will likely invalidate a lot of the details, or worse, you'll try to keep the adjustments to a minimum in order to be able to follow the plan.

Some things definitely require planning, and if you haven't got the skill for making the required level of plan, then the only way forward I can imagine is prototyping, writing code simply to gain the experience with the task required to make an adequate plan.

Whether or not you are ready to write production code, once you have reached your maximum level of planning there is nothing left to do but coding. Maybe it will be a disaster, but those are good learning experiences, and you will be much better equipped for making a revised plan.

aaaaaaaaaaaa
  • 1,076
  • 6
  • 11
5

You absolutely must have some design before coding.

The reason is pretty straightforward - if you don't have any design, you don't know what you are making.

You absolutely must have some code before the design is final.

The reason is pretty straightforward - the design will change, and developing parts of the design will reveal questions, opportunities, and challenges that are hard to anticipate without starting to work on the solution.

Development is iterative.

Whether by plan or not, whether the team realizes it or not, every software project is done iteratively -- part of the work is completed, and then evaluated, and the evaluation leads to changes in how the rest of the work gets done.

Try more than one approach.

It takes practice and experience to know the best way to balance up-front design against creating code. It's a skill that almost no one has mastered and each project will have different ideals (consider designing a small tool for your own use versus a team creating a large, single-release product like a major video game).

asfallows
  • 2,331
  • 19
  • 18
1

I've designed and obseved others design multiple systems in the past and I've seen the process unfold in many different ways, but what I find common is that the initial architecture should at least plan for the existance of most major features.

For example I've seen an HVAC control system that had no concept of buildings, floors, rooms etc being retrofitted with those and the result was as ugly as they come. Or a mobile music device built out from components better suited for your (non-smart) pocket watch. Needless to say the end products in either case weren't customers' favorites.

When you say "conception" that's only one step up from "idea" and a concept can be very fuzzy. Business usually cares about concepts. Customers usually care about UX - a concept brought to reality in a way that's easy and pleasant to use and brings some value through its use.

You have to do "concept" before any programming, I can't envision myself opening visual studio (or your IDE of choice) and randomly writing code, to see where it goes.

You may not do a complete design (and you shouldn't) before coding but you should have a rough sketch of what the user's workflow would be.

UX design and coding quite often feed off each-other, you'll likely be forced to use some Agile approach for anything but smallest of projects as a way to incorporate this fact into how you approach the work. So don't think you're the worst of programmers if you couldn't see it all at once - nobody can and the people who think they can are the ones who just ignore enough of the problem so they can claim they have a complete picture.

One example to put a size to something big. Concept: "Create a visual cloud-based tool that allows businesses to integrate their software platforms". This sounds great and one can start writing up marketing material and sell it before it's even there. You have to have this before coding.

Pre-design: "Have shapes and arrows like in Visio to describe logic; have plug-in capabilities to allow connections to various platforms (SAP, SF, databases...); have a monitoring console where one can search data passing through the system; have a way of describing data visually and transform one format to another". Another great marketing blob. It also gives you some ideas on what's important, should have such a rough sketch before coding too.

Design/Code: "Have a browser hosted HTML designer with such and such features; code the backend in Java so it can run on any existing server; define data structures and UX for querying or modifying them as needed; plan for disaster recovery, error reporting, audit logging; plan version control; plan access control;...." - the finer the list the more unrealistic it is to foresee all of it.

... however one should be at least aware of what things might end up looking like roughly or your final product may end up with some really useless implementations that end up killing the otherwise great-sounding concept - say your visual designer requires a 40" screen to show any real-world workflow, or there's no way to search the logs other than an exact string match limited to one of the 20 fields in the log etc etc. There's no good way to prevent this from happening other than executing your implementation - some will succeed, others will fail.

Sten Petrov
  • 489
  • 4
  • 10
0

I always allot time as follows:

  1. 1/3 Design
  2. 1/3 Development
  3. 1/3 Testing

Design: Not only visual, but also conceptual. Divide it into parts, both visually and by logic. Look for commonalities which are re-use and are a design pattern in themselves.

Development: Once you know your parts, code them. Then you integrate them.

Testing: Not just testing that the code was integrated and written properly, invariably there will be insights spotted and lessons learned and it'll create new ways to interact, new capabilities will be conceived and desired. Beware of scope creep.

In addition to these aspects, be aware that a project also has 3 phases on top of these phases.

  1. The under-engineered first attempt
  2. The over-engineered second attempt, from lessons learned from the 1st attempt.
  3. The properly engineered 3rd attempt.

I have found that the better you do the design phase, that it minimizes the additional attempts. Instead of re-doing the whole thing, you might have just a sub-system that gets reworked.

I am a software developer, and software development manager for in-house, outsourced and off-shore development projects.

user9170
  • 109
  • 2
-2

There's a fundamental incorrect assumption here. You will never be able to come up with a good design without writing code first (school will never teach you this). Yet, school is right that you won't get good code without design.

The solution is:

  1. Write some code that you think might solve the problem.
  2. Come up with a design based on what you learned from the code.
  3. Throw away all the code and rewrite it from scratch according to the design.
  4. Repeat as necessary.

Throwing away all the code is not an optional step in this process, but for small projects formally writing up the design may be. For large projects, you're more likely to repeat the "throw away all the code" step - though if you have sufficient modularity this may only apply to part of the codebase.

Far too many projects hold onto legacy code because they're unwilling to change it - or because it's too complicated, because it was never designed to be thrown away. Acknowledging the fact that your first attempt will be a failure will make your life much better.

o11c
  • 588
  • 2
  • 6
  • 1
    There are many valid reasons not to throw away old code. Could you please provide some reference to back the last paragraph. – mattnz May 23 '14 at 04:47
  • +1. Don't know why this was downvoted. "Build one to throw it away" is a classic Fred Brooks advice. – nikie May 23 '14 at 12:40
  • I think in this case the old code is from a prototype and there is a danger of prototypes being considered good enough and thrown into production. Throw it away in regards to the current project and not literally. – JeffO May 23 '14 at 15:27
-3

conception is the key design can always be changed programming will have to meet the requirements of the fully conceived app.

1st whats the point, 2nd how does it need to be accessed, 3rd who the user is, 4th lay out a full SOW scope of the work define in specific terms all this application is to do. and how each function you add will work.

before any choices are made as to the architecture of you web app, plan and think it through completely.

then pick the best stack

I am a LAMP developer

so I tend to narrow the question to what php framework i will use. and the front end scripts i will need to make it do all the things i need it to do in a ideal way

to add this, learn to use MVC frameworks, ZEND and CAKEPHP are the best rapid development frameworks ( PHP)

kevin
  • 1
  • 1
  • 7
    "*Pick the best stack ... I'm a LAMP developer*" - While it is perfectly ok to stick to someone's knitting, that statement sounds like a slight contradiction, doesn't it? – JensG May 22 '14 at 20:16