How do you manage to write high quality code very quickly?Can you give some advice on how to maintain the code quality at a high level when you have to finish as soon as possible.
ACCEPTED]
The more you know, the faster you can write good code. It's all about the experience. – Will [1]
This is a two fold statement.
Know your tools:
The better you know your particular language, framework, and your tools the faster you will be able to express what you are trying to do.
Know your problem:
The better you know the problem you are programming against the faster you will program it. This is extremely important. Sometimes people find technical specs and pre-planning a real drag but understanding and working out the problem ahead of the time is a huge time saver in the end.
I'm sure many of us have experienced programming a type of program with it taking us weeks but then we have to reimplement something similar and we can do it in a couple days.
[1] http://stackoverflow.com/users/1228/willWrite less code.
This can be achieved by:
First two require experience, last two require good language/framework that is the correct one for the job at hand.
References:
[1] http://www.codinghorror.com/blog/2007/05/the-best-code-is-no-code-at-all.htmlUnit testing, Unit testing , Unit testing
Some explanation is called for. If you need to write a mock up, you might be able to get away with some coding without unit testing. BUT if you need to write code that would not blow up in five minutes, unit testing would make your work faster.
In the past for every N hours of coding I would spend 3N hours debugging. Today for every N lines of code I write 1/3 of N lines of unit tests, and my code is (almost) bug free. This is huge time saving since most of the debugging time is saved.
My best guess is experience. Using a language with an underlying framework also really helps. Turnaround time in C# (and maybe VB.NET) is very high due to the ability to leverage the framework and language features that make encapsulation much easier.
I would say small testable work pieces. One of the main reasons of delay in code production for me is the time I "waste" (not so wasted in long-term) to think and design for the overall system instead of the local problem.
When I need something fast I try to keep the testable pieces small, forget the whole design and trust the experience that the small pieces will fit together well in the long run.
You need to be well-prepared in order to write high-quality quickly.
Specifically, you need to have an excellent code base on which to build, and you need to know that code base well.
Then, you need to plan the project carefully, and resist the temptation to start coding without clear specifications.
So - good training will lead to faster, higher-quality code generation.
I use a comparatively uncomplicated language (complicated syntax takes longer to write and makes errors more likely) and then on top of the language I have a framework I developed that automates a large number of my common, day-to-day tasks in a convention over configuration (CoC) and Don't Repeat Yourself (DRY) manner. The use of CoC and DRY techniques reduces the amount of code I have to write for a new project. Writing less code means both getting it done faster and having less code to maintain. This way I'm typically only writing new or custom code if it's for a feature that is actually new or custom.
Convention over Configuration [1] essentially means "if you always know before you write a particular line of code what that line of code will look like, use a default so you don't have to write that line of code". Or in other words, only write configuration when your application must behave in an unusual manner. If the application is behaving in a "typical" or "normal" manner, this should require no coding.
The idea behind Don't Repeat Yourself [2] is fairly similar. If you've written code for a particular behavior already, you shouldn't have to write it again. Also, avoid copy-and-paste at all costs.
I also avoid development techniques that involve code-generators as I personally find them to be an easy way to create more code to maintain and thereby more maintenance headaches.
Your mileage may vary.
My preferred language is ColdFusion. The frameworks I prefer are the onTap MVC++ framework [3] and the DataFaucet ORM [4].
Pete Bell [5] is known to do a pretty good job at building quality applications very quickly in several different languages (ASP, PHP, CF), although I believe he uses code generators to accomplish this. So his approach is rather different than mine.
[1] http://en.wikipedia.org/wiki/Convention_over_configurationYou know the teory: quick, cheap, good quality - pick two. So, a critical element for code quality under a tight schedule is, obviously, a lot of money. ;)
No, seriously. Motivation is the key; find what motivates you, that's the answer to your question.
Another one word answer: Refactor.
I don't think that the best code can be written without changes any more than great literature can be written as a first draft. A "bug" in the design of an application can easily force you to create awkward code to compensate for it. If you are just trying to get to the end of a cycle, you will wind-up compromising and using opaque methods, copying code whatever. But if you have your test methods in place, you will be able to refactor as you continue.
Martin Fowler talks about the concept of "technical debt". This implies that there are short-cuts that an organization can and will take if it is up against a deadline and these short-cuts have long term costs. Taking on "technical debt" is not always a bad decision. One simply has to be willing to pay your technical in the form of refactoring and redesign over time.
Modern agile methodologies are actually very good at not encouraging programmers to push themselves to be supermen (or superwomen). There are no silver bullets for writing bug-free, perfectly formed code the first time but there approaches which let you stay on track to improve your code base over time.
I pare down my initial designs to as few features as possible, implement that core, then work my way out from there. This way, critical things happen first, so there's a working application relatively early in the actual coding process. Even if I know what a lot of the other features will be, that core is easier to debug without adding them in at the same time.
I design ahead of time. If I have design ideas while implementing, I write them down in a separate file for later. Designing and implementing are very different mindsets for me, doing them together means doing neither well.
I select soundtracks carefully. Music that gets me going with enthusiasm is great for brainstorming phases, but not great for actual coding. For coding I want music (or lack of) that inspires me to near-Vulcan precision. This helps me detect edge cases and strange error conditions, and prevents me from glossing over things. I also use diet, ergonomics, and exercise routines to promote that mindset for coding sessions. Not reaching that mindset results in so many bugs that I spend more time fixing it than I would have spent waiting and writing it later.
I work in time blocks of at least a couple of hours. Interruptions prevent reaching the really high-level mental states that allow tracking a lot of details at once. Not just external interruptions, being interrupted by thoughts about other topics interferes too, so I like having a GTD system to capture those and get them out of my way.
One way that a lot of developers will write a lot of code efficiently is with tools such as CodeRush and ReSharper (or SQL guys will use RedGate products like SQL Prompt and Refactor on their queries).
high quality tools, libs, and programming practice. code that catches errors at compile and even run time will speed production time up.
High quality code and tight schedule do not make a good mixture. It takes time to produce quality, though at some time, you hit the point of diminishing returns.
The best thing you can do is write a lot of code. Nothing beats experience. Think about the people that you know that are very good at writing code. They are always writing code - they always have their editor open. They are experimenting with code. They are practicing with code. They are reading about code. They are reading other people's code. They are always the last one to stand up and be ready to leave for lunch because they are writing code. They are always the last one to a meeting because they were writing code. They are always late for dinner because they lost track of time because they were engrossed in writing code. Get the idea? Be that guy/gal.
The best advice I've gotten from JoelOnSoftware is "open up the editor and start coding."
A lot of things help (big monitors, task-specific frameworks/tools, refactoring, unit testing (maybe), code-generators, etc, etc), but they all have a relatively minor impact when compared to just having written a lot of code.
The best example I can think of is Jonathan Colton and his Thing-A-Week with music. He realized the best thing he can do to learn to be a good musician is write/perform a LOT. So, he makes sure he writes a song every week. Or at least he did in the beginning. You gotta spend a lot of time doing it before you'll get good at it. And if you spend a lot of time doing it... you'll get good at it. (Which means writing quality code in a timely manner... careful with "fast").
Practice. Practice. Practice!
Here are a couple suggestions that I think will help:
The Joel Tests, 12 steps to better code, here is the link: http://www.joelonsoftware.com/articles/fog0000000043.html
Use a high level coding framework (I suggest ASP.NET or Java).
Someone must be in charge of maintaining your company shared code. Where I work there is a ton of duplication of code which really slows down development. If someone is in charge of all the shared code and all your developers ask that person first before writing new code, chances might be that the code they need will already be written.
If you really want to get code complete as fast as possible, code first and ask questions later. Spend a short amount of time describing what you want in plain English, and maybe do some mock screenshots. The bulk of your time should be spent in coding your project to a point where it can be demo'd.
Nothing to add, just trying to come up with a formula that summarises many of the other answers:
Speed + Quality is possible if
because
on top of which
A corollary: if the project involves a new technology or a new area of business, you shouldn't expect both speed and quality.
Many good things have been said above. I'm going to focus on programming languages, where I have special expertise.
You can only write so many lines per hour and still pay attention, so pick an expressive programming language that packs a lot of computation into each line. This choice matters a lot.
Pick a language and environment that offers good support for random testing and unit testing.
If robustness and reliability are important to you, the best quality/speed tradeoffs come from languages with powerful, flexible, expressive static type systems.
Expect to spend a lot of time mastering the languages, tools, and techniques that will enable you to write a lot of high-quality code fast.
As far as meeting the criteria above:
Many languages pack a lot of computation into a few lines; examples include F#, Haskell, Lua, ML, Python, Ruby, Smalltalk, and Scheme.
Of these languages only F#, Haskell, and ML have a powerful, flexible, expressive static type system.
For testing, QuickCheck [1] and SmallCheck [2] are unsurpassed in their ability to create effective tests almost instantly. QuickCheck is available for Haskell and Erlang; SmallCheck is available only for Haskell.
It's not hard to get started in Haskell, but it takes a long time to master, especially that powerful type system. If you already know .NET you may prefer to try to master F#, which may be a quicker path to where you're going. At that point you can use F# on some projects, assess how you are doing, and consider whether you want to try Haskell lated. (The two languages are cousins.)
build a good code base from which you build on. Not all projects will be able to be built off this but from my experience most of my projects are similar and can be derived from something I've already done. Another thing I've found to be a way to get a project done quickly and high quality is be sure you completely understand the expectation of the business and then also have test scenarios your tester will use. This way your unit test will be more accurate.
One good strategy is to delay starting coding as long as you can stand it - write down the Use Case as thoroughly as you can, to flush out ambiguities and technical risks. Then resolve the ambiguities (on paper). Then make a check list of the technical risks, along with a written statement of code you will need to write to execute a test that resolves the risks.
Then work through the checklist.
Then start on the Use case, and code like mad.
I generally find I can write high-quality code quickly by just getting on with it and using years of experience.
What I can not do quickly is PROVE that it is high-quality... testing/validation always seems to take much longer than writing the code in the first place!!!
Design first. Then code. The code will be better and it will be done sooner.
--
bmb
Do not use design patterns, do not think to the future (forget base classes and interfaces), do it right as it comes to your mind.
Wait until V2 to do things by the book.
Quality have a cost that, most of the time, user are not eager to pay for. They want it now. Not tomorrow with some intangible gains.
Use a high level language and make sure you don't repeat yourself. If you recognize duplication in your code, you have to rewrite it right away.
Also, don't manually perform tedious repetitive tasks. Automate these right away.
That's it! Unfortunately, it takes years of practice to do these things well quickly. So at first, this is going to slow you down, and you'll have to put in more hours.
Code can only be as insightful, correct and anticipatory of potential problems as the brain behind the code.
If you want high quality code and the deadline was yesterday, I will suggest pair programming. Industry numbers suggest that 2 sets of eyeballs will ensure that the code quality stays high. Unit testing is of course still mandatory :-).
If it's "need it yesterday", then I'd say keep it simple, keep it small. And pair program.
If it's a more strategic approach you're looking for, this is worth reading: http://www.amazon.co.uk/Rapid-Development-Taming-Software-Schedules/dp/1556159005 [1]
[1] http://rads.stackoverflow.com/amzn/click/1556159005If someone using your app./code without hesitation after several years that is itself high quality code for sure.
Solid, high quality code comes with knowledge and experience; for tight schedules you should plan project steps carefully. Every steps must be achieve in time. For that time You should aware of time consuming processes, bottlenecks and faulty codes.
I personally have a problem with overthinking my problems. I find that I do much better when I'm not trying to account for each and every corner case that may or may not even be possible (not that you don't need to consider corner cases).
Boil it down to it's essence and use the simplest tool(s) that integrate as quickly and efficiently as possible to get an end result.
Lots of good advice here. I like use good tools, master a good language, experience, reuse code/do not repeat, create conventions/base cases where the exception is the only time you need to change or add args, start with basic core funcionality/build from there, etc. Sometimes good music, not too loud, and NO DISTRACTIONS. that no distractions things is me. I hate distractions when im trying to reach a high level state of mind. Take breaks when needed. Think your problem over for days before you get started. Understand your problem. These are the best tips I ever got and seem to work the best. Look at lots of code, read lots of info about good coding, and practice writing a lot of good functioning code!
