Hints for making programming even more pleasant

Question

After my first large project, I've understood there are lots of things that can make programming more pleasant at such projects. I know some already but what else I could yet do when preparing for large projects?

What I've learned this far:

• Minimize your requirements list for the project.
• Set up a repository. (*)
• Version your code. (*)
• Provide something early as possible.
• Automate your testing routines.
• Make deployment easy as possible.
• Research and take your time, do not hurry.
• Set up a bug tracking website.

• Find out and search ways to make programming more pleasant.

  (*) forgot to add.

I've written these out as bullet points, but I'd like to see the reasoning and experience behind the new ones you provide. As an exchange I can try explain my own reasoning and experience behind these points one-by-one.

Minimize your requirements list for the project

It is inevitable that your application has requirements it must fulfill. I burned myself with them because I took the requirements directly from my client, without refining or reducing them in any way. On top of that, I added couple more.

There's a straight relationship between requirements and how long it will take. It will take longer more you have requirements. So I went way out from the schedule I had for the project.

Only after I finished my project I realized that it would have been much easier if I had reduced the client's requirements into minimum, and not providing any more requirements for the software.

Perhaps it is already half-designed when it's requirements are minimized and re-structured properly. Anyway, before you do that you may not even have clear requirements specified by your client.

Set up a repository and version your code

It is nice to work with code if you don't need to store dead code in comments and if you can just send the patches to the server you are working to. It also makes it much easier to work with a team if you happen to have one. When you version your code, you can make sure that people can tell the version where the bug appears. It does not matter if you only have one customer though.

Repositories and versions are so easy to configure and use, that it doesn't hurt if they are there always.

Provide something early as possible

While lacking remote repositories. I couldn't provide anything for a month, therefore the client couldn't try out the software until late and only at certain moments. If you can provide something early as possible and then update it gradually, you'll have couple of eyes more at trying it out and seeing how it works most of the time. This also helps the customer realize what do they want and make their move accordingly, while giving the feeling of progress.

Automate your testing routines

It may not look so big deal at small projects, anyway you just need to test whether they do few things correctly. It's also so hard sometimes that there's no interest on doing it. But you end up having much to try out any non-trivial application. Therefore it's your interest to make most of the testing automatic.

Unfortunately I didn't do this. When I write a fix I don't know whether it broke anything obviously unless I test it by trying it out. Bugs coming from bugfixes are ending up to the end-user. It further also takes my time onto things I could have otherwise used to thinking out a better design.

Make deployment easy as possible

Making deployment easy is as important as actually producing the product in the end. Program should solve it's dependencies, download or contain them. If it doesn't, you or the end-user will end up looking and solving for them. Unfortunately, most programming environments do not help in it as much as they should. You have things to do, no time for solving out the dependencies in whatever mess you end up touching to or moving around.

Research and take your time, do not hurry

I program regardless of whether I'm employed or not. During the project I realized that I don't behave same when employed. I tended to try get it all fast done, to get back to my own projects. That must been one factor why it failed so badly, because after I got it released and stopped having any pressures, I found out many places from my code where I could have done really much better without any tradeoffs I had to take before. I believe this has something to do with the importance of analysis in the programming.

Set up a bug tracking website

This is not always so high priority in projects where there's only one or two end-users. But it gets more important on large projects where your customer base can clutter your email box full.

I don't perhaps need to explain the last point. It's self-explaining thing.

Answer 1

• set up a source control repository ;) (rationale: your code does not exist until it is managed under source control) Meaning:

  • Think about your merge workflow (is your development sequential or not ?)

• establish the different architectures (business vs. application) The application architecture will help you manage and divide efficiently the different modules your project need to develop.

• Think about the metrics you want to have (and especially the trends you want to monitor)

Answer 2

Not a bad list to start.

• Read up on continous integration, which encompasses some of the practices you mention and more.
• Try out Test Driven Development.
• Get yourself a larger, or second, screen
• Spend less time on SO in working hours
• Work a normal working week with only the infrequent exception.

Answer 3

Everyone has made good points. I give a specific thing:

Never ever, ever ever over-generalize a system beyond the requirements for the task. They call it "gold-plating". Never do it, and you will remain happy.

Answer 4

Especially if you're going to have several people on the project, consider getting familiar with some agile process (for example XP or Scrum) and specially a bit with the forces, values and principles behing these. This will provide some background for many of the practices suggested Automatic testing, TDD, Continuous Integration, early Deployment.

To get overview of the values and principles behing "agile", check out Agile Manifesto. To get some more insight, some books worth reading would be for example Extreme Programming Explained (Kent Beck) or Agile software development with Scrum (Schwaber, Beedle). Also googling for agile, XP or Scrum will provide many resources, like

Agile won't maybe be the thing for every project but many of the practices mentioned here are used with agile processes and these could provide some background. Note also that you shouldn't try to fit some "agile process" straight by the book but search and find out the practices etc that fit your project.

This isn't actually an short, practical answer but some thoughts. Even if you're doing the project yourself, these resources can provide insight. Some thoughts still to add:

• Communicate with the customer or whoever you're doing the project for
• Communicate among the team

Answer 5

How about good old UNIX philosophy? Not all of it applies everywhere. Use your judgement (though don't be too quick to reject these ideas!).

Answer 6

Try to always talk complex design issues through with your team - you will almost always end up with a better design.

Answer 7

I would highly recommend reading a book called The Pragmatic Programmer. It contains a few ideas such as:

• bullet-proofing your code using assertions - when you are coding you make assumptions, and if these are wrong it can cause problems. So if you include assertions this will throw up a problem straight away if one of your assumptions is wrong.
• use "Design by contract", i.e. include a 'contract' above all of your methods to ensure that your code is doing what it's supposed to do.

All these things will help particularly on a large project. I found it immensely helpful and it's a book I will keep going back to :-)

Answer 8

Make sure that you sit near other team members as it makes it so much easier to share information. This is especially important for junior staff members with much to learn. One of the most successful projects I've been on had a relatively junior team of five sitting facing each other with an experienced lead passing on his wisdom and imparting good practice.

Answer 9

Never be afraid to redesign or rewrite. After all, you're not discarding the source to the earlier project -- it's still on disk or in version control, and you're smarter now than you were before.

This frees you up from feeling like you have to come up with all the requirements at the start, or having to work around deficiencies in your current project.

Usually us programmers are lazy and don't hit the opposite problem, excessive rewriting, too often.

---

Find an environment that you feel comfortable in (this includes language, libraries, editor, monitor, chair, music, etc.). Low stress, good documentation, being able to reliably predict "X broke, the problem must be in component Y" (even if both parts are outside of your own control), and having the freedom to focus without distractions is are major boons.

---

Take breaks. Don't pull too many all-nighters.

---

Talk with other people about your work. Be proud enough of your own accomplishments to show off :) yet humble enough to accept that your work isn't perfect (or even close).

Answer 10

A few non-technical ideas that may help:

Have a clear structure for how conflicts will get resolved. If there are ambiguities in the requirements, these may need to be refined or changed. Try to have a place where there isn't much ego preventing humility and ample sharing of talent and that second set of eyes that can help make things better.

Ensure that how work is divided up is clear. If someone finishes their current task, do they know how to find another task? If someone is discovering what was initially thought of as simple turns out to be more complicated, how does this get communicated so that it doesn't become a big roadblock in getting things done.

At various completion points, recognize if someone is giving an extraordinary effort. Even a simple "Thank you" in front of others can do wonders to help keep some people going.