There are a lot of software development practices and processes out there today: automated unit testing, refactoring, code reviews, design patterns, test-driven design, domain-driven design, XP, agile, and so on.
My question for you guys is simple: which practices and processes have had the most profound impact on your development, and why?
Peer review: both doing them, and receiving them, as you learn more about coding and alternative practices that way.
Design Patterns: learn new ways to do the same old thing, with improvements.
Coding, Coding, and More Coding: the best way to learn is to do, and to teach.
Design patterns. Not the forced and inappropriate use of design patterns because they're trendy, but the experience-driven development and refinement of reusable methodologies that work better for a particular set of related purposes.
They have a profound impact because they allow me to accomplish more, more easily, and better leverage what I've already done toward what I need to do.
I am going to say design patterns and here is why, I am a web developer at a small company and I work very closely with designers. Designers are always changing their minds and with out proper design patterns the code becomes very ugly and hard to maintain. With proper design patterns making changes because all that much easier.
The ability to repeatedly and reproducibly run the same tests on code allow for better practices all around. You can refactor code, fix bugs, and do anything else you'd like with an existing codebase and know much more readily the side effects you may have caused. Without unit tests, programming is done like driving with blinders on.
Not a practice, but it helps alot:
The walk to the coffee machine.
Sometimes you are busy doing something, and deep inside you know it is wrong. But your stubborn ego shields this flash of briliancy from the outside.
In this cases you should stop and walk.
If you return you will have the right solution in 95% of the cases. And as a bonus helps to fight against RSI buildup.
Things like peer review, pairing, etc apply more to larger teams. As a solo developer/team of 1-2 developers, the most valuable practices are:
These apply to development in general, but its a very good idea to do market research, and write a functional specs document before you get started coding.
Edit: I should include Touch typing, I'm only in the learning stages right now but i can see it would help a lot. I found This resource and its really fantastic.
Early on right out of college I was part of code reviews. I will never forget that. It was a tremendous help to me to learn how to code in the real world and learn form others.
It fell out of my day to day practice until I was put in charge of a development team. It worked wonders for that team as well.
Mentoring was another huge help. I participated on both sides there as well. That was another eye-opener.
Other than that I would say do what interests you. There are tons of practices and processes out there. Pick one you think might address a particular weakness in your organization, or one that appeals to you. My pet projects were testing and profiling for a while.
EDIT I almost forgot - a dedicated build machine. At the time when I first heard of it I was shocked. This was contrary to how one of my groups worked about 13 years ago. But it made sense then and it makes sense now. A formal/repeatable build process that does not rely on human interaction is pretty important.
That's always helpful when finding bugs or rather making sure that what you've done is really what you've expected. The quality of your work is measured by the quality of your tests. There's also a good saying: if something is worth writing it is worth testing - if it's not worth testing it's not worth writing.
With that practice I'm almost always more productive and for most of the time I'm really glad to have someone that just watches over the code that I wrote (and vice versa).
That's something not every employer will go for as it's just mostly time that will go to waste (in the pure sense of a spike). Of course it teaches you how to deal with problems but in some cases you're hired to do the job not to learn (believe me there are still some companies looking at developers this way!).
The XP practice of "do the simplest thing that will work". Too often in the past (5+ yrs) I would succumb to the old re-use mantra of trying to design a thing to be all things - now and in the future. I always ended up with something way more complex that I really needed, but justified it on the basis that "someday I will want this and it will be really useful".
Of course, some day came, and I invariably ended up totally re-writing the thing because it didn't really do what I now wanted, and was complex enough that it was quicker to re-write than to modify.
So now, I frequently remind myself when designing new code to just "do the simplest thing that will work". The code is WAY cleaner as a result, and usually solves the problem neatly and efficiently. In those rare cases where I later discover I need the same type of code, it's very quick and simple to revisit the code and and just those mods required for the new use.
Cheers,
-Richard
I'm just about to start to get a grapple on TDD, and an emerging observation is this: I am able to program while drinking more beer - without loosing control over my code. I was not able to do that with the traditional approach.
Agile would be my biggest helper, including Scrum as part of that. Agile provides a way to handle those changes that can happen over and over again as someone changes their mind about the software since what they originally envisioned isn't likely to be what is first written, but rather after refining requirements over and over again, the finish line becomes more clear since there is a diminishing return after a while and that produces a stopping point.
Scrum meanwhile provides some nice visibility and accountability to what I and the rest of my team do each day. In the daily stand-ups, I get to hear what others are working on and plan to work on so I know where everyone else is while also in giving where I am and where I am going gives an accountability that can be used as if I say the same thing 3 days in a row, chances are it is either bigger than I first thought, not decomposed into small chunks, or just really hard to get done.
Good tools! (esp. debuggers)
Compare the feedback you get from digital cameras vs. "chemical" cameras. The digital ones make it so much easier to learn quickly from your results. Now imagine an infrared camera in the dark without a viewfinder looking at something that you can't see, and trying to take professional-looking pictures.... that's what life without a good debugger is like. Sometimes on embedded systems it's still like that... :/
Notepad: As in paper & pen. My most elegant solutions always come after fleshing out a problem on paper. The multi-user version Whiteboard is also extremely useful for teams.
Constant re-factoring to eliminate duplication of code.
The less code you have, the fewer mistakes will be made.
On Test-Driven development - this can be helpful but like any process you should beware it getting away from you and taking up more time than actual development. If you really cannot make changes to code without tests to prove the change is safe, perhaps the code has grown too complex and dependent and intertwined with other code.
That leads into another danger of test-driven development, that there will be more resistance to good code re-factoring because tests will have to change as well. An important part of test-driven success is to realize that at some point some tests are better off retired rather than maintained, and to be aware of that as you are doing maintenance changes to code. Think of tests like scaffolding, where perhaps some tests that really help put together a large bit of code do not make as much sense to leave in place once the main structure of your code is complete.
There is no single methodology out there that is a silver bullet, but they all offer something good. I've tried many methodologies on many different projects and take away something new each time. I feel like I'm iterating towards the "right" way to write software, though I never expect to find the global maximum.
I hate to say it, but I think that my current process is based on "feel". It's kind of instinctive. Of course inside my brain are thousands of lessons learned and I expect my auto-pilot keys off them.
Having said that, there are a few very important aspects of process that are always on my mind:
Maintain an open, transparent development process where the current state of things can be communicated quickly and easily. Communication within your team and with eternal parties will improve with every step you make in this direction. I find that this leads to better interactions in the team/company, more involvement of non-technical staff and a general feeling that everyone is batting for the same team.
Check your ego at the door. Primadonna developers are horrid. They may make some good short term gains, but they will divide your team and kill your culture. Interestingly, those with an ego problem seems to fail in an environment as described in (1).
Focus on reuse, decoupling, layered design and lightweight frameworks. Although each is important in their own right, all of these lead to one important thing - thorough unit testing. If you're not unit testing, then you putting all your hard work at risk.
Focus on design. So many methodologies focus on coding. Code should merely be an expression of your design. It is so much easier to change a design when it's just a UML diagram on a white board than it is to re-write thousands of lines of code. Have you ever found yourself scratching your head while writing code thinking, "this'll never work"? Most times that's a design error that should have been picked up before you started coding. Focus on design and your implementation will follow.
Be iterative and cater for change.
I think that (4) is not promoted enough in most modern methodologies. They tend focus heavily on requirements (user stories, etc) and code with no real thought given to the complex transfer function between the two.
Code Reviews are a great way to ensure high quality code and coherent teams. Team members that have become accustomed to having their code review make sure to bring their best efforts forward instead of just shlacking on more code.
Reading industry forums, websites, blogs and books. The best people that I know in the industry make it a point to constantly adapt and improve their skillset. You'll notice the inverse of this is also true.
Decent Tracking Tools: Basecamp, JIRA/FogBugz, etc. If you can make consistent use of tracking tools you'll find that they'll get out of your way and cover your butt later when you lose track of where you were at. It is a normal engineering tendency to try to keep everything in your head -- it doesn't scale.
Oh, and stay away from Scrum. It isn't inherently evil or anything, but underperformers seem to flock to it. Keep good company.
Lots of good stuff here, but since you asked what helps the most, I'll give two answers:
When working alone, test-driven development does the most for my productivity, development speed, and quality of results.
When working with others, code reviews are unsurpassed as a way of making a system better, simpler, smarter, and faster.
I could not do without our automated nightly build system, we get build notification emails on the build's success or failure, along with the build log, and links to the binaries on a shared server
I would like to eventually couple that with automated unit testing and code coverage analysis, but that will hopefully be implemented in the future
Don't get hung up on methodology, I think Joel on Software was the one who said it best in his book. Long story short, methodologies do not make great developers alone. Just practice clean consistent code that follows best practices, as well as keep yourself well practiced in the general SDLC (Gather requirements, design, develop, test, implement) and you'll do great in IT.