I find myself pondering over this question again and again. I want to do things the right way: to write clean, understandable, and correct code that is easy to maintain. However, what I end up doing is writing patch upon a patch just because there is no time, clients are waiting, a bug should be fixed overnight, the company is losing money on this problem, a manager is pressing hard, etc.

I know perfectly well that in the long term I am wasting more time on these patches, but as this time spans months of work nobody cares. Also, as one of my managers used to say: "we don't know if there will be a long term if we don't fix it now."

I am sure I am not the only one entrapped in these endless real/ideal choice cycles. So how do you, my fellow programmers, cope with this?

A happy medium?

I may draw some flack for this—but if time is of the essence, then your main priority should be to get it working, simple as that. Comment extensively about the shortcomings in your code and make a note of what you've done in any project/time management software you're using. Hopefully this will give you more time to return to these issues and make them perfect.

Obviously there is no absolute correct answer to this, but it's an answer I try and stick to. You may not find it suited to your current work style though. Which leads me on to the alternative...

Find a method that works for you; and then stick with it. Everyone has their own way of dealing with projects and there's no "one size fits all" approach. Find an approach, and make it yours.

Don't make cutting corners a policy

I see my job as providing the best quality software that is possible within the time constraints allowed for the project. If I am concerned that the level of quality will be low, then I will engage the project owner. I describe my concerns and discuss the potential risks of deploying the software in that state. One of 3 things will happen at this point:

The project owner will not want to accept the risks and will move the schedule back to allow us to spend more time on software quality.

The project owner will not want to accept the risks but cannot move the schedule back. If this happens, then we need to negotiate on what features/functionality to remove from project scope in order to spend more time on software quality for the main parts of the application.

The project owner will accept the risks and the low quality software will go out on schedule. Sometimes the business risk of deploying nothing (or deploying late) is much greater than the business risk of deploying low quality software, and only the project owner can make that decision.

Writing software is a lot like painting a portrait. It is impossible to say that a portrait is done "right" or "perfectly." Perfect is the enemy of done. You could literally spend 1 month working on a single method and it still might not be considered "perfect" by some. My job is to paint a portrait that the customer is happy with.

Weigh the costs

The optimal balance may be to spend as much extra time doing it right as you would waste fixing the bugs you eliminate by doing it right. Avoid gold-plating the solution. In most cases the Volkswagen solution done right is as good as the Cadillac solution. You can usually upgrade later when it is proven you need the Cadillac.

Fixing code that hasn't followed best practices often take much longer. Trying to find where the null is coming from when the call looks like a.b.c.d.e(), can take a long time.

Applying DRY and reusing existing code is usually much faster than coding and testing yet another solution. It also makes it easier to apply changes when they do occur. You only need to change and test one set of code, not two, three, or twenty.

Aim for solid basic code. A lot of time can be wasted trying to make it perfect. There are best practices that lead to code which is fast, but not necessarily the fastest it could be. Beyond that, trying to anticipate bottlenecks and optimize the code as it is built can be wasted time. Even worse, the optimization may slow the code down.

Whenever possible, provide the minimal working solution. I have seen weeks wasted gold plating solutions. Be extremely careful about scope.

At least the used car salesman knows he's lying

Actually, this is a very difficult question because there is no absolutely right answer. In our organization we have been putting better processes in place to produce better code. We updated our coding standards to reflect how we, as a group, write code, and we have instituted a very strong test/refactor/design/code loop. We deliver continually or at least try to. At the very least, we have something to show the stakeholders every two weeks. We feel that we are software craftsmen and morale is high. But, despite all these checks and balances, we suffer from the same problem you do.

At the end of the day, we are delivering a product to a paying customer. This customer has needs and expectations, realistic or not. Often the sales team gets us into trouble just to get a commission. Sometimes the customer has go-live expectations that are unrealistic or demand change even though we have a contract in place. Timelines happen. PTO and lost days during a sprint can happen. All sorts of little things can culminate in a situation where we are forced into the conundrum of "do it right" or "do it ASAP." Almost always, we are forced to "do it ASAP."

As software craftsmen, developers, programmers, people who code for a job, it is our natural inclination to "do it right." "Do it ASAP" is what happens when we work to survive, as most of us do. The balance is hard.

I always start by approaching executive management (I am Director of Software Development and an active developer in that group) to defend the schedule, team, and work being done. Usually at that point I'm told the customer has to have it now and it has to work. When I know there is no room for negotiation or give, I go back and work with the team to see what corners can be cut. I won't sacrifice quality in the feature that is driving the customer's need to get it ASAP, but something will go and it will get pushed into another sprint. This is almost always OK.

When you are unable to deliver because there are so many bugs, code quality is bad and getting worse, and timelines are getting shorter, then you are in a different situation than what I describe. In that case current or past mismanagement, bad development practices that led to poor code quality, or other factors may be taking you on a death march.

My opinion here is to do your best to defend good code and best practices to start pulling your company out of the trenches. If there isn't a single colleague willing to listen or go to bat for the group against management, then it might be time to start looking for a new job.

In the end, real life trumps all. If you are working for a company that needs to sell what you are developing, then you will encounter this trade-off daily. Only by striving to achieve good development principles early on have I been successful at staying ahead of the code quality curve.

The push and pull between developers and salesmen reminds me of a joke. "What's the difference between a used car salesman and a software salesman? At least the used car salesman knows he is lying." Keep your chin up and try to "do the right thing" as you go.

Find the original post here. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to ask your own.

I run into this problem daily. Honestly, every single day. You learn to choose your battles. I've found that I never *ever* get all the time I actually need to write something the way I want. So you take some shortcuts (emphasis on "some") and focus on error checking and commenting. I can't stress "error checking" and "commenting" enough.

That way, 2 years down the road when something goes wrong, at least the next developer has an idea of where to begin upgrading functionality/fix problems/redesign/etc.

Only the great programmers I know know how to properly balance this golden "Do it right vs Do it now" rule, and it takes years to develop a keen ability to do this well. That said, you're *highly* desirable as a prospective hire if you can prove this to me.

Any software development has three components: Time, Money and Quality. You only get to choose two.

That's not just software development. I've had a few non-it jobs in my time and the same sentiment always held true. Whether I was washing dishes at 15 or installing kitchens years later between it jobs.

I remember having a discussion with my cabinet installation super about the time constraints effect on quality. Every job seems to require 3 days worth of punch work. It seemed like taking an extra day to do it right the first time would make more sense. He didn't agree. Eventually I got back in to IT managed services but started my own little company.

I know that answer isn't feesable for everyone but if you can do it, you have a lot less people to answer to. And once you get busy enough, you can just turn down the headache customers.

Any software development has three components: Time, Money and Quality. You only get to choose two.

And this is why open-source projects are good. They have Time and make Quality code.

I can agree with this to a point, but there's always a tradeoff. You don't usually have as many dedicated code gurus in an open source project. Coding standards are harder to adhere to since you have an enormous melting pot of developer resources. In my coding groups we litterally sit down as a group and talk about best practices if we begin to see a recurring theme in poor coding quality. It's much more difficult to meet as a group with an open source project, especially if one of your largest and most beneficial contributors is outside the core group.

That said, I love open source projects. Mozilla's Firefox project is one of the world's greatest examples that pretty much everyone knows about. But it's also managed exceptionally well, with tons of dedicated resources always on hand.

This one of the blurry and soft questions in programming, that is just ugly as there is no right answer and no golden way and no useful formalism to guide you. This is where programming crosses with the arts.

Personally, my experience is that it the answer to good or fast lies in the balance and this balance is different for every single project I ever worked on. Most of the time, you only see what would have been right in hindsight.

I always try to see what I do in a bigger picture and from a business perspective. Is this code going to be the core and foundation for something really big? Then it definitely is worth to aim for high quality and make concessions elsewhere, as problems might haunt you forever. This might apply to such simple things as declaring an interchange format for sensor data...Of course you never know for sure how long your code will live and how important it will be.

The business perspective is basically to estimate how good code has to be and whether making it better pays off. Customer needs stuff now and loses money if there's nothing. Is the horror of delivering half-assed and straightening out worth it or not? Does the extra seven days spent to make things good pay off directly through easier maintenance, less patches? Does it pay off by the better impression?

In the end, it is a guts decision. I've met quite some people who I think do better in this than me, and every single one of them basically said when asked how he decides how to approach this, that it's mainly just guts and vague guesstimates.

And in practice having the time to do stuff right always bears the potential to go wrong. Overengineered stuff so abstract and orthogonal and fancy that using it is as good and hard as programming an ad hoc solution may happen then.

Practical advice would be to monitor time spent for projects closely to build a historical basis to judge by. Then guesstimate if taking more time from the start would have saved you more on maintaining and fixing stuff.

I do not code but I deal with this all the time working on projects at work. I work for a very large multinational company who places a very big emphasis on doing it right, yet forces strict financial discipline and places unmoving deadlines. Thus, there are inevitable compromises.

The worst are projects I get involved in that are half-a$$ed at the beginning to meet the strict deadline at the time but they have no vision for the future. This results in more time and money invested in it later that would have been saved had it simply been done correctly in the beginning. It blows my mind..

If you work at a fast-moving startup and need to demonstrate that your product is marketable, you might need to code it fast and refactor it later. If you work at a slow-moving company like IBM, you probably have the time to perfect the product, as the fate of the company does not hinge on it.

I don't think this question can be answered properly without knowing about the culture and financial needs of the company.

The key is to keep the time horizons short and to avoid surprising the product owners or customers. Break big projects down into small pieces that can brought to a demo-able or releasable state on a short development cycle (one month max). Some teams alternate between development cycles and maintenance cycles, others budget for maintenance work in each cycle so as to not disrupt the flow of new features and enhancements.

There may be the occasional defect where it is business-critical to fix right away and blow up the plan. But project managers, together with their development teams, need to train their product owners to recognize that most defects can wait two weeks. The goal is to break the cycle of bounding from crisis to crisis and stick to a cycle of progressing from plan to plan.

The stakeholders will feel a lot better about your project when they know what you're going to deliver, even if they're not getting 100% of what they want exactly when they want it. The most important thing is to identity when things are not going to plan as early as possible so that product owner can go work on controlling expectations and avoiding surprises. If your stakeholders get burned by a surprise failure to deliver, they will make your life more difficult for the next few cycles at least.

That last part cannot be emphasized enough. If you surprise your stakeholders, you will be forced back into the cyclical crisis mode and will have to fight your way out of it again. The product owner will revert to demanding things be done yesterday, and the planning process will deteriorate, ultimately leading to the stakeholders having less of an idea of what's going to be delivered than they had before.

See, you can do it fast - chuck it at the customer and then spend a lot of time fixing it up, or you can do it "right" in an ivory-tower implementation that'll never be perfect. OR you can do both things - write a system that is not perfection but you get it released, that is done quickly enough to satisfy the customer whilst still being of good quality.

Its like the old 80/20 rule - if you try to do 100% fast, you'll fail. If you try to do it 100% perfect, you'll fail. If you try to do it 80% fast and 80% perfect, chances are you'll achieve both to those levels. That balance is what you should always aim for, its not like the choices are so exclusive that you can't incorporate some of both.

I do not code but I deal with this all the time working on projects at work. I work for a very large multinational company who places a very big emphasis on doing it right, yet forces strict financial discipline and places unmoving deadlines. Thus, there are inevitable compromises.

The worst are projects I get involved in that are half-a$$ed at the beginning to meet the strict deadline at the time but they have no vision for the future. This results in more time and money invested in it later that would have been saved had it simply been done correctly in the beginning. It blows my mind..

Try working in Telecom. Most of the people you work with have no idea what they need to do to make it right, then you couple that with lack of resources, add to it the ridiculous time lines set by people who have no knowledge of what is required technically to achieve the objective. If you put up processes to encourage a little best practices, they escalate to the top and run you over, then when it gets launched half broken they're screaming at you to fix it. There is no winning this battle. You just go with what the business dictates because they pay your salary. The best advice I can give is don't go too far out of your way to achieve perfection when the business has been made aware of the risks and is prepared to accept them.

Well, I'll give a perspective from slightly up the ladder: no one gives a damn whether your code is 'good'.

Code has to be bug-free and timely. If it's written in Sanskrit? Don't care. We'll address the problem of no one being able to read the damn thing down the line as long as it works.

I've seen far too many programmers get obsessed with making sure every variable follows some wonky naming convention or that they comment every line. But you know what? Almost no one is ever going to read your code anyway - there's even a good chance it will be replaced entirely. And the folks who do read your code can probably figure out what you're doing from the code itself.

On the other hand, if you don't get your code done in a timely manner, no one will ever read your code because your company will lose the contract.

"The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time."Tom Cargill, Bell Labs

This isn't just coding; this is an issue with any project, ever. I've never written code, at all, but I have done projects for work.

I do this: get the bare minimum done ASAP, then go back and refine as I can depending on the timeline and the perceived importance of any givne part of the project.

You'll always find SOMETHING you misjudged on--either you glossed over something that turned out to be more important or sunk more time than you needed somewhere, but it's workable. I'm not yet great at it, but I think I will be with practice.

@Avaviel's comic is absolutely true. Both "right" and "asap" will lead your project to failure. You can't aim for either one.

If you wait until something is finished it will never ship. And ASAP is also useless, because if you slap something together quickly it will be junk, and nobody will use your stuff unless it is better than the competition.

You need to find a middle ground that will be different for every project. Decide exactly how you want it to work, and then spend as long as it takes to get it to that point. Then call the thing finished. Resist the temptation to continue improving your code and ship it.

You can always make improvements later on, and you will never run out of improvements. UNIX was released 44 years ago according to wikipedia, and improvements are still being added to it. Clearly, unix isn't "right" yet or else they would have run out of things to change. You don't want to spend 44 years working on something that nobody ever sees, because you always have a long list of stuff that isn't right yet.

You don't usually have as many dedicated code gurus in an open source project. Coding standards are harder to adhere to since you have an enormous melting pot of developer resources.

Coding standards are trivial to adhere to.

Unless the other contributor's code is as good or better than your own code standards, tell them to get lost (or at least go away and come back with an improved patch). You don't have to accept patches from anybody, they can create a fork if they want.

JFDI (Just Fuckin' Do It) syndrome is in most cases a cancer for enterprise IT projects; a slow burning, deadly cancer that goes unnoticed for years. Almost all the time it is because of bad management but unfortunately sometimes it is because of bad programming. Signs that this culture exists:

1) Do you often see the blame game happen after a problem?2) Do teams work together or are they "not my job" oriented in silos.3) Are budgets and capital planned without talking to anyone that will actually code the features?4) Are your projects loaded with emergency fires?...

JFDI is the most visible symptom of terrible management budgeting practices. The first mistake many directors, VPs and managers make is thinking that they are any good at estimating. The estimates lead to terrible budgets and wildly unrealistic project deadlines. Then when their prognostications do not come true, they go into crisis mode and everything is a fire; JFDI they say; we'll catch up on the next project (hahahahaha). It's a project management death spiral, anchored by the trail of technical debt that is left in the wake of JFDI, poor budgeting, terrible project management and last but not least, bad programming.

The cycle continues to spiral in on itself until the team is bankrupt. Technical debt weighs so heavily on the team, that everything is a fire and it takes a collosal lift to reverse the trend. Eventually technical debt MUST be paid. Your first step to being afforded the opportunity to do it right, is to get everyone to realize when they are taking on technical debt. Convince management to categorize it alongside other projects in the pipeline. Point out every time it bites you in the ass. Force management to realize that it is real and it MUST be paid. Then as you pay the debt, develop an adverse reaction to taking on more debt, even if it is a painful refactor of code that is heavily laden with technical debt from the past. Short term, you'll slow down. As you pay off the debt, you'll get a chance to do it right and then can look at how your team can evolve into a software team that can "manage" change, instead of reacting to change. Managing change is the higher evolved order of our craft. You're only good at it after you've discovered that most of the time you suck at managing change and you actively develop code with change in mind. Project management, budgeting and programming all have to work towards managing change because that feature you write today will be ported to 3 - 4 OSes, 3 - 4 databases and go through dozens of iterations of business requirements before it is rewritten. Do you write code that can survive this? more? the unknown? That's when you'l know you're doing it right.

Well, I'll give a perspective from slightly up the ladder: no one gives a damn whether your code is 'good'.

Code has to be bug-free and timely. If it's written in Sanskrit? Don't care. We'll address the problem of no one being able to read the damn thing down the line as long as it works.

I've seen far too many programmers get obsessed with making sure every variable follows some wonky naming convention or that they comment every line. But you know what? Almost no one is ever going to read your code anyway - there's even a good chance it will be replaced entirely. And the folks who do read your code can probably figure out what you're doing from the code itself.

On the other hand, if you don't get your code done in a timely manner, no one will ever read your code because your company will lose the contract.

You should probably do some reading on technical debt and the problems created with the "no one cares how good your code is" mentality. There are some good resources in this thread, and while you might not care now what the quality of your code is, when it's had to live through three developers and you're trying to bring the new person up to speed, you'll find that insane code is a lot worse than sane code, simply by default. "We don't care how good your code is" costs in ways that are not obvious years down the road. Decisions like that are how you end up on The Daily WTF and find yourself asking questions like "Why do we have problems hanging on to all our good developers?"

Well, I'll give a perspective from slightly up the ladder: no one gives a damn whether your code is 'good'.

Code has to be bug-free and timely. If it's written in Sanskrit? Don't care. We'll address the problem of no one being able to read the damn thing down the line as long as it works.

I've seen far too many programmers get obsessed with making sure every variable follows some wonky naming convention or that they comment every line. But you know what? Almost no one is ever going to read your code anyway - there's even a good chance it will be replaced entirely. And the folks who do read your code can probably figure out what you're doing from the code itself.

On the other hand, if you don't get your code done in a timely manner, no one will ever read your code because your company will lose the contract.

You should probably do some reading on technical debt and the problems created with the "no one cares how good your code is" mentality. There are some good resources in this thread, and while you might not care now what the quality of your code is, when it's had to live through three developers and you're trying to bring the new person up to speed, you'll find that insane code is a lot worse than sane code, simply by default. "We don't care how good your code is" costs in ways that are not obvious years down the road. Decisions like that are how you end up on The Daily WTF and find yourself asking questions like "Why do we have problems hanging on to all our good developers?"

Linux, Chrome and Mozilla are examples of good planning and fine management.The incremental development model, with rapid iterations can deliver satisfactory software solutions. It is good to start with small working code, and carefully extend it with new features. Problem solving deals with finding out what is the problem and then figuring out different alternative ways to fix the problem. While developing an improved solution, often the greatest technological innovations are created. All with a small increments.

It is good to have in your project:- Well defined modular architecture.- Compartimentalised software components with clearly defined interfaces.

"According to program manager Anthony Laforge, the increased pace is designed to address three main goals:- One is to get new features out to users faster. - The second is make the release schedule predictable and therefore easier to plan which features will be included and which features will be targeted for later releases. - Third, and most counterintuitive, is to cut the level of stress for Chrome developers.

Release is like a predictable train and features like wagons added when ready and not before.Laforge explains that the shorter, predictable time periods between releases are more like “trains leaving Grand Central Station.” New features that are ready don’t have to wait for others that are taking longer to complete—they can just hop on the current release “train.” This can in turn take the pressure off developers to rush to get other features done, since another release train will be coming in six weeks. And they can rest easy knowing their work isn’t holding the train from leaving the station."

Well, I'll give a perspective from slightly up the ladder: no one gives a damn whether your code is 'good'.

The next person to work on the code sure as hell cares, but hey, they're not in the management club so they don't matter?

Zarko wrote:

Code has to be bug-free and timely.

Agreed, no argument here.

Zarko wrote:

If it's written in Sanskrit? Don't care. We'll address the problem of no one being able to read the damn thing down the line as long as it works.

This will cost you time and money, unless the next person to work on it is fluent in Sanskrit* too. And even then, if it's written in flowery or poorly-constructed Sanskrit, it's still going to cost you time and money for the next person to be able to understand it before they can do anything with it.

* insert name of programming language here

Zarko wrote:

I've seen far too many programmers get obsessed with making sure every variable follows some wonky naming convention or that they comment every line.

Wonky naming conventions and comments on every line are NOT the signs of good code. If you're a developer and you think this, you're part of the problem. I think you're probably not a developer though.

Zarko wrote:

But you know what? Almost no one is ever going to read your code anyway - there's even a good chance it will be replaced entirely.

Or, if the code is produced with an eye to making it well-structured from the start, then it will be a doddle for other people to read it, and mean that it's kept around and gradually modified over time, rather than binning it because it's such a tangled mess that it would take longer to make the necessary changes than start over.

Zarko wrote:

And the folks who do read your code can probably figure out what you're doing from the code itself.

You say that in a way that makes me, a seasoned developer, think you haven't had the misfortune of working on a badly structured codebase. Because if you had, you'd know that this is most definitely not always the case. The times when it is feel like heaven. I struggle to understand my OWN code six months down the line, sometimes, and try to send good vibes back in time to past-me when I find something I've written that is extremely clear.

Maybe that's why writing good code feels so good; because I'm receiving the good vibes from future-me as I do it...

Zarko wrote:

On the other hand, if you don't get your code done in a timely manner, no one will ever read your code because your company will lose the contract.

This is another point to agree with, but it doesn't mean you shouldn't attempt to make the client aware of limitations and future repercussions of hacking out a steaming pile just to hit an unrealistic deadline.

Any software development has three components: Time, Money and Quality. You only get to choose two.

And this is why open-source projects are good. They have Time and make Quality code.

Yeah... No.

The parent post quoted it badly. The choice is usually formulated as: Cheap, good or on time. Choose two.

Since volunteer based open source is by definition cheap, they usually have to choose between on time or good. If they release when it is done, it is great. Set arbritary dead-lines and feature requirements, and open source projects will crash and burn worse than the Hindenburg.

I have a similar dilemma when doing custom internal systems for our company. For us, computational bugs aren't the issue so much as user interfaces being complicit in user error.

The tradeoff is generally between good user interfaces and required development time. All else being held equal, if a program will only be used by a handful of people, less time will be spent on making interaction efficient or less error prone. However if the software will be used by many people in multiple departments, it gets a far more polished user interface. Similarly, accuracy is more critical in areas that could impact customer health.

Interestingly, attempting to codify the decision making process for this would be counter productive. The time spent analyzing efficiency would consume more time than it saves. With a small, skilled development team and a smart, long term employee doing managing, gut feelings are the most effective for us.

Do it right and do it fast. This is what experience gives you. The problem is that IT departments think only young people can code. And they pay for it thru their lack of experience.

Sounds like a personal experience has made you bitter.

Take heart, there are good, well-run IT departments out there. It is unfortunate that you haven't had the pleasure of spending your career in one.

I work as a contractor. I have worked in both the private sector and for the government. i have seen many more IT dept. than most. There may be good, well-run shops out there but they're few and far between.

I've worked with perfect hack coders before, and it's annoying. Sure they produce some brilliant, elegant solutions, but at half the speed (if you're lucky). You need to respond to the work chain. If there's time pressure then get your stuff working quickly and then hopefully into test. It's not an excuse to produce shit code, but it doesn't need to be Michelangelo.

The only time that I feel like I have good code is when I have full control of the project and the requirements are stable. Unfortunately the requirements always change. It is a constant trade off however if you are constantly finding yourself in a position where you have to put out something that will be difficult to maintain just to meet deadlines it means that you have a serious development problem. At some point of all that technical debt will derail your project. You need to keep away of the building debt and keep it balanced like a checkbook. The key is to not let your project run away from you. Quality control is the responsibility of everyone in the business. If you are the developer and your concerns are being neglected make sure that you express the cost and benefits clearly and respectfully. This will be a constant challenge but you must communicate effectively and accept whatever decisions are made.

Do it right and do it fast. This is what experience gives you. The problem is that IT departments think only young people can code. And they pay for it thru their lack of experience.

Young? Most of the developers I meet are in their lat 30's. At 29 I'm the young guy and despite being only 29 I have a lot of experience since I started when I was 11.

Regardless, experience does allow you to work faster while maintaining quality. However, as incredibly valuable as general experience and a solid grasp of the fundamentals is, you still need experience with the specific technologies being used to guarantee a swift development process. This is the issue that I suspect older developers tend to neglect. You have to keep up your skills up to date with the project being developed.

Do it right and do it fast. This is what experience gives you. The problem is that IT departments think only young people can code. And they pay for it thru their lack of experience.

Young? Most of the developers I meet are in their lat 30's. At 29 I'm the young guy and despite being only 29 I have a lot of experience since I started when I was 11.

Regardless, experience does allow you to work faster while maintaining quality. However, as incredibly valuable as general experience and a solid grasp of the fundamentals is, you still need experience with the specific technologies being used to guarantee a swift development process. This is the issue that I suspect older developers tend to neglect. You have to keep up your skills up to date with the project being developed.

What experience gives you is a whole collections of algorithms you can adapt. Yes, code reuse is a wonderful thing but even today, most code reuse is copy, paste, and refactor. What experience also gives you is the ability to comment as you code. Knowing what the algorithm is before it is written let's you write better comments.