If you are doing something short and simple you can jump right in and start coding.

However once things start to get even the least bit complex, I find its good to start thinking about methodologies, design patterns, documentation, coding conventions ......

Even on something as simple as a one man two week project.

I am not saying you should treat everything like its the next space shuttle launch, but you should be able to go back a year latter and easily understand what you did and why you did it.

Sometimes you will even want to go a bit overboard on the short & simple projects if you see the potential for part of it to become a reusable component.

"They don’t think about the fact that in two years or even less, when they want to make a change, they’ll have such spaghetti code that the programmers will have to go through hell to change anything."

Use any methodology you want, but don't write spaghetti code in the first place - problem solved.

Actually, I think we SHOULD treat every code as a new Shuttle launch. It's because there are all these "little things" that are developed on the side that we have a maintenance problem.

The little projects, supposedly unimportant, are likely going to become indispensable to those who use them. Maintaining them becomes mandatory, and that can entail major changes a few years down the road, changes that become costly because the initial framework was not implemented in a way that allows the new requirements to be implemented correctly.

So I am actually a partisan of going back to a monolothic IT service, one that controls every bit of code that runs on the servers.

I would also very much like to see all developers work the same way. The Internet allows anyone to read up on a programming language, and helps him to start coding, but there is nothing to teach a newbie how to think about the code. Thus, thousands of people go for the DIY approach, and develop catastrophic coding habits that take years to grow out of (if they ever do).

And I'm not sure that school makes things better. I don't remember much emphasis on programming methods back when I was in class.

This situation is going to have to improve if we want code that can be more easily maintained.

Yeah, I just hack and do whatever I feel like, too. I'm so professional.

"Maintaining [the little projects] becomes mandatory, and that can entail major changes a few years down the road, changes that become costly because the initial framework was not implemented in a way that allows the new requirements to be implemented correctly."

Your post reads like a recipe for Big Up Front Design, which is the antithesis of agile. Good luck with that. People are very bad at generalising from single examples, or projecting future requirements before they can see a working product.

Code for today, keep the costs of change low through decent test coverage, add complexity only when required.

And above all else, don't let stupid people near a keyboard.

John

Using a methodology is a good idea.

Will it prevent developers from writing spaghetti code? No.