Best practices?

[HarryF]

Sounds like a great environment to work in (esp. the 4 day week) Can I have a job?

Where I work it's almost the exact opposite (if I can what you're doing excellent).

Edit:


Body removed for reasons of good sense

But we do have a CVS server!

I've ranted many a time but these days, as a father, it's easier not to.

Worst practices?

[lastcraft]

Hi.

Oops. You know when you ask a question and suddenly wished you hadn't.

yours, Marcus

[samsm]

Hi.
Oops. You know when you ask a question and suddenly wished you hadn't.
yours, Marcus

Speaking as someone who is pretty much a hobbyist without much formal academic background or training in computing, I kind of rely upon accounts like yours and other's in this thread to give me an idea of what is or is not considered good practice.

I also rely upon accounts like Harry's to remind me that maybe I wouldn't like the professional world of programming so much. I suppose it varies by company. So when are you switching jobs, Harry? :-)

I'm currently in the process of creating an application for analyzing histories of currency rates (I'm actually trying to make it general enough to perform any kind of forecast, but that's another version :-) ). Version 2 works beautifully and incorporates a lot of OOP design which I am really happy about. Version 3 steps up the level of sophistication about 20 notches and due to this added complexity I'm having to do a lot of thinking about best practices. Basically, V2 was simple enough that I could describe it to you without the aid of looking at it or notes about it. Because of that, I could quickly fix and hack problems in a number of ways without having to go to too much trouble. V3 is a whole new ballpark for me, there are enough different classes and interactions that notes are going to be essential and there will probably be a substantial amount of rewriting as I discover what is working and what isn't.

Certainly there is a great deal of difference between an eight person, 35 hour week project and what I am doing, a one person eight hour a week project. However, best practices are possibly even more valuable for me because I am working at so much slower of a pace. If I've had a busy week or two then come back to code I was working on before, I might as well be another person... my notes and comments have often turned to total nonsense. Best practices could be the difference between this project taking 3 weeks, and, say, 20 weeks. Seriously, count me getting discouraged in there and it could easily be that much of a difference.

A friend of mine is involved in this project. I have more programming experience than him (eeek!), but when we have done pair programming, things have been accomplished much faster, even when I've been doing nearly all the actual programming. For example, at one point we were getting obviously wrong results. My "pair" took the keyboard as I was getting frustrated and added "echos" everywhere to document what was happening so that the error in the program would reveal itself. After a few examinations, the problem was discovered, and my sanity was maintained at a key moment. After that point we were on the road to getting the whole thing done that nigh rather than a week or two postponement.

Anyway, my overall point is that I like hearing real world stories about "best practices". Certainly Harry's story is somewhat of the dark-side but that doesn't mean we can't learn from the good as well as the bad. It's a good thread, I tell you!

[Selkirk]

Well, here is my large company experience:

From 1991 to 2000, I worked on three versions of a similar product for a large manufacturing company. The company grew from $1 billion annual sales to $2 billion in the period of time I was there.

The product, WGS, handled order entry, pricing, invoicing, manufacturing scheduling, warehouse management, and shipping. There were also various minor systems. The system also had major interfaces to accounting and procurement systems.



From 1991 to 1994, I worked on what I will call V0.

This was a pre-WGS system that was developed at and worked at only one manufacturing facility. The system was written by the subsidiary co-founder and president, a Physics P.h.d. I was hired to do maintenance work along with two other programmers and the president.

BEST PRACTICES:

CUSTOMER FOCUS
Since the president of the company had written the software, it was an amazing match to the business needs of the company. It had many advanced features that were ahead of its time. An ecommerce module in 1992! EDI support. Profitability analysis built into the order entry program.

WORST PRACTICES:

COPY & PASTE
The original programmer had a copy & paste style of programming. The thing was he never deleted any code that wasn't used, He just inserted GOTO statements to bypass the unused code. (written in BASIC) Oh, and whats a subroutine?

NO SOURCE CODE CONTROL
There was no source code control. Versioning was a nightmare. Code got lost. Old versions were re-installed.

LESSONS:

• The idea of refactoring was an essential survival tactic while working on this code, because only about 40% to 50% of any given program was actually "live" code. Working on anything meant having to re-write the code just to understand what it was doing. Yet, this had to be done while preserving the original function because the programs were so intertwined that you might not necessarily understand everything at once. I really learned about refactoring here, although I didn't have a name for it.
• Even the worst programmers can make an application that actually works and meets the customers expectation. Providing value to the customer is more important that writing good code.
• If you have 2 developers on your project and you don't use source code control, you are committing malpractice.

From 1994 to 1996, I worked on V1 of WGS. The project began in 1992-3 and was installed in its first plant only a few months after I came on the project, although many modules had not yet been written.

WGS was designed to replace individual systems written at each facility. (just like the V0 that I worked on before) I think WGS today runs about 40 manufacturing plants in the US, Canada, germany, poland, hungary, luxembourg, spain, venezuela, brazil, thailand. Maybe even india, saudi arabia and some new countries by now.

WGS staffing was about a dozen developers. Based on comparing our project data to data from SPR.COM, I once figured out that a normal project of the same size would have about 70 developers working on it. We were highly productive.

I would consider this project to be mostly successful. (other prior efforts of corporate standardization had failed) WGS delivered a working, highly customized system at perhaps 1/5 the cost of purchasing an off the shelf solution which probably would not have fit the companies exact needs.

BEST PRACTICES:

ON SITE DEVELOPMENT
100% of the development for WGS took place while in the customer's facility. We sat at desks in the sales office while working on order entry programs. We sat out by the loading dock while writing warehouse management programs. The users of the programs knew us by name. After the first plant was launched (the one closest to corporate HQ), we spent about 25% of our time traveling to each new plant where the software was to be installed. The other 75% of the time we were at our home manufacturing plant. Not at HQ.

INCREMENTAL DEVELOPMENT
The software was developed one system and one plant at a time. Many plants had vastly different business models. We didn't worry too much about what other plants were doing. We scheduled them to be converted over one at a time. As part of the process, we would analyze what new features they would need. A team of developers would travel to their plant and implement what they needed on site. Other developers would travel to prior plants updating them with new features. Old stuff was re-worked to accommodate new stuff.

SOURCE CODE CONTROL
With so much travel, we maintained a centralized source code control system. It was essential.

SHARED OWNERSHIP
Because developers would travel to plants as corporate representatives, they would be responsible for resolving all issues that the plant had during their visit. (Plants would save up major bugs/issues/feature requests for a visit.) Because of this, each developer had to have a general working knowledge of the entire system and might have to fix bugs in any part of the system.
We still had code that was "owned" by individual developers. However, usually changes to this were negotiated over the phone by the owner and the on site representative. (note that the roles could be reversed the very next week. There was no real specialization. If you wrote bad code, your peers would call you and shame you)

CODING STANDARDS
We all had pretty much the same style of programming. We worked together alot.

NO DOCUMENTATION. NO DESIGN DOCUMENTS.
Yes. I consider this to be a best practice. All design work was done with transient artifacts: whiteboards, napkins, and conversations. We talked a lot. We sat next to the people who were using our programs.

SCRIPTING LANGUAGE
We used a dynamically typed compiled language that did not require memory management. We had amazing productivity with this language. Its only recently with PHP that I realize how much of a factor this was.

WORST PRACTICES:

COPY & PASTE PROGRAMMING
I once found a bug in an early code structure. As part of the fixing process I found that the original buggy code had been copied, pasted and modified over 2000 times.
Based on my prior experiences, I would do some refactoring in secret. I could never get anyone interested in refactoring as a processes. (it still didn't have a name)
Eventually the code got to the point were the system was so big and complicated that every programmer was literally afraid to make all but the most minor changes to existing programs, and some were even afraid of that.

DATABASE ORIENTED
So much of our design process was built around designing the tables to store the necessary data, and then writing simple CRUD programs. As a result, WGS was considered to be very difficult to use by the end users. What as lost in the mix were the tasks that the user performed. For the worst example, entering a new part into the system might involve pulling up as many as twenty different screens in a half a dozen different programs because there were twenty different tables involved in the process.

LESSONS LEARNED:

• Sitting one desk away from your customer can make up for almost every kind of technical sin you can commit on a project.
• It is possible to develop MASSIVE systems one small step at a time.
• If you don't keep your code in order, eventually you will succumb to the fear of change.

V2. Ah, V2. V2 started about 1996 as an effort to port V1 WGS from DOS to windows. As I understand It, seven years later, it has yet to deliver any working code into a production system. (I left the company three years ago)

BEST PRACTICES:

UNIT TESTING
Late in the project we started practicing unit testing. We all but eliminated GPFs from our code. Our developers were very confident about the quality of the unit tested code. They were not afraid to make changes.

WORST PRACTICES:

LEARNING OO ON A LARGE SYSTEM
It took us years to learn some crucial lessons about OO. We should have hired OO experts early instead of teaching ourselves. We should have used it on some small projects which could be deployed to get feed back.

REWRITE THE WHOLE THING
Instead of replacing one small piece of the system and then moving on to the next piece, we tried to replace the whole thing all at once.

NO REFACTORING CULTURE
Everyone was afraid to make V1 changes, so we didn't want V2 to have "bad code" like V1. So instead of doing a straight incremental port of the "bad code" to windows, we tried to do a rewrite. If we had more of a culture of refactoring, we could have had more confidence in our ability to refactor our way from ugly DOS code to nice windows code.

LOW LEVEL LANGUAGE
We used a language which required memory management and static typing. productivity was glacial. Business programmers should never worry about memory or GPFs.

SPECIALIZATION
Instead of each developer being a jack of all trades, we each took a specialized area. We had designers, new feature programmers, maintenance programmers, support, documenters & installers. We lost track of what was going on elsewhere. The vision of and experienced designer throwing design documents over the cubical wall to a contract programmer never worked.

NO CUSTOMER
Development took place 100% at the corporate office. Whats a customer? No urgency.

BIG DESIGN UP FRONT
Because we all worked on V1 for years (there was virtually no turnover -- it was a great company to work for) we intimately knew how complicated it was. We thought we could get it all down on paper and design our way out of the complexity.
We thought that many of the problems with V1 could have been avoided had we done more design on V1 up front.
I no longer think that is true. Now I think that one of the only reasons that we were able to complete V1 at all was that we didn't do a big design up front.

CASE TOOLS
Rational Rose & others. Especially in the beginning. WORSE than useless.

I could go on and on, but thats probably enough.

[Andy Tomaka]

Man. I know this is going to sound really..nerdy...but I cannot wait until I actually get to do this stuff I think I'll be one of those few people who actually enjoy their jobs. I have thoroughly enjoyed reading this thread and can't wait until I have an actual chance to do some of this stuff and maybe even contribute to it soemday

[Dr Livingston]

If you have 2 developers on your project and you don't use source code control, you are committing malpractice.

Does that carry a life sentence ?

[Taoism]

I guess I can chime in with how we do things here (at the moment).

Version control
We use CVSNT, and WinCVS to interface (I have both Python and TCL for running scripts through WinCVS to automate things).

I can't say enough about version control. Even developing solo projects on the side I never code without version control.

Iterative Development
I would consider our development iterative from the perspective that we do new releases to a testing server on a semi-frequent basis. However, we don't have any "set in stone" timelines for a release cycle.

Tracking of Issues in development
We do things like create a versioned "Issues" document and add to it any issues that people raise at meetings, etc. We then address them in a code update, and add our comments to the issues document for what we have done. The issues document is sent out (via email) as often as needed (sometimes 4 times in a week, sometimes 1 time in three weeks), and people who have a say in the project can reply back with comments or new issues, and all these are added to the document. Items that are "closed" are left in the document but are set tohave a grey background so that still open issues stand out. The document is given a new version number before each new mail out so the old versions are always around (in case, for example, we decide to start removing closed issues to reduce the size of the document, and an older closed issue was still needed).

Code Ownership
Anyone here can make a change to any code as long as they fully understand the implications of said change. If someone makes a change that buggers up an app because they didn't know the implications, and didn't ask about the implications, I get annoyed

But, things like CVS help to allieviate these problems. As well, we are more and more using Marcus' SimpleTest to write testing harnesses. However, our older code doesn't have that benefit Which brings me to

Unit Testing
We are making a string effort to do Unit testing going forward in our development. Sometimes we write the tests before we code, sometimes after. But they are and will be a much larger part of our development effort in time.

UML
I don't do UML diagramming nearly as much as I would like (and perhaps should), but on more complex applications it is certainly one of the first things I think to do.

Refactoring
We do refactoring in more of an ongoing sense. If a coder is working on a module and decides that it would benefit from being refactored (and the refactoring won't impact other things in a negative way), then they can refactor the code. We don't allocate specific time for refactoring right now.

Code Docs
We document all objects (no exceptions) in phpDoc syntax. If I pull a class from CVS and it is not properly documented I send it back to the code with instructions to make it a high priority to add the comments. And I will follow up to ensure the comments were added.

We also work with the Fusebox framework here, so we document our Fuses using the Fusedoc documenting standard. I find that writing a Fusedoc can help a great deal in thinking an application through. However, (sad confession here) I will admit to, on an all too frequent basis, writing some Fusedocs after I write the Fuse (when it should really be the other way around).

Documenting can be a headache especially when people make code updates and don't update the documentation to match the new code (if needed). But it is definitely worth it in the end.

Specification Documentation
For every project I try to create a "Functional Specification" Document. It is in essence, an overview of the project, and how the application will flow. It remains fairly non-technical (except for a specific technical section), but does go into some detail about what will happen for various interactions.

Here is (part) of one from live application:

Structure Change Calculator

Functional Specification
This document describes a functional specification - how a product will work entirely from the user's perspective. It talks about features. It specifies screens, menus, dialogs, and so on.

This document includes a section called Technical Notes, which contains additional details of a more technical nature (data structures, data models, choice of programming languages and tools, algorithms, etc.). A non-technical reader can safely skip the Technical Notes section.
Overview
The Structure Change Calculator (SCC) is an application that allows users to enter data about their farming operations to help them determine if they will be in a structure change position for the current processing year.

The SCC takes a “wizard” type approach in walking the user through the process of calculating their structure change position.

This spec is not complete or final. It is expected that this specification will grow and change with the nature of the application.
Non-Goals
There are no non-goals to mention at this time
Interfaces
The interfaces of the SCC will be a series of wizard pages the user steps through to add financial information about their farming operations before seeing a final result page.

Display
The following display interfaces have been identified:
- main
- help
- wizpage5

Input
The following input interfaces have been identified:
- wizpage1
- wizpage2
- wizpage3
- wizpage4

Interface Descriptions
The SCC contains several interfaces as outlined above.
main
This is the starting point of the SCC. The user will see an introduction page here and links to wizpage1 and scchelp.
wizpage1
The user will see a form that allows them to choose a province from a drop down list box (DDLB). The user will also see a “next” button to proceed to the next page.
wizpage2
This page is displayed only if the province selected in wizpage1 contains municipalities. If the province selected does not have municipalities, the user proceeds directly to wizpage3. If it does have municipalities, the user is asked to select one from a DDLB. The user can navigate from here via “next” and “previous” buttons.
wizpage3
The user will be presented with several inputs on this page. The user must enter previous year margin history for between 3 and 5 years. They must also choose whether or not this is a non-calendar year-end operation. Finally they must also enter a percentage of ownership of this operation.

The rest of the page is optional to fill out depending on the user’s operations. The rest of this page deals with crop information. There are several rows of “static” crops that are so common they are already shown on the page, and there is a DDLB from which the user can select less common crops. The user can enter 5 years of data for each crop type.

The user can navigate from here via “next”, “previous”, and “add row” buttons. The “add row” button will add a new blank DDLB crop row for the user to add additional crops as long as there is no blank one that has not had data entered into it. The “previous” button is displayed only if the user has not entered more than one operation, otherwise the user can no longer modify the information relevant to the location of the operation.

Once the entry of a second operation (see wizpage4 for more details) has started, an additional DDLB menu appears at the top of the page to allow the user to navigate to any of the previously entered operations to modify their data. When the user jumps to another operation to modify the data, they are always taken to wizpage3 to start navigating from there.
wizpage4
The use can enter livestock data on this page. It is the same layout as wizpage3, but without the previous margin history, non-calendar selection, and percentage ownership (they are only needed once per operation).

There are several rows of “static” livestock that are so common they are always shown. There is also a DDLB where the use can select less common livestock. The user can enter up to 5 years of data for each livestock item.

The use can navigate via, “previous”, “add row”, “add operation”, and “calculate” buttons. The “add row” button will add a new, blank, DDLB livestock row for the user to add additional livestock types as long as there are currently no blank DDLB rows on the page. The “add operation” button will take the user back to wizpage3 so the user can add data for a second operation. The “calculate” button takes the user to the last page of the calculator to view the final results of the structure change calculation.

If the user is navigating back to this page after having entered more than one operation’s worth of data, an additional DDLB menu appears at the top of the page to allow the user to navigate to any of the previously entered operations to modify their data. When the user jumps to another operation to modify the data, they are always taken to wizpage3 to start navigating from there.

wizpage5
The wizpage5 interface is where the final results of all the calculations are displayed. All the data previously entered by the user is used to calculate the final results to be displayed here.

The user can navigate via “previous”, and “start over” buttons. The “start over” button will clear all results and take the user back to wizpage1 to enter all new data.
help
The help interface is accessed in one of two ways. If the user browses to the full help listing (scc.help) all the help topics are shown on one page. If the user clicks a help icon while using the calculator they are shown a pop-up window that contains help information relevant to the topic the icon was next to.

There is an additional Technical section which I won't post because it goes into details of how things operate in the background. It describes the actual processing steps, db calls, validation, decisions, db table diagrams, etc that will occur behind the scenes as a user moves from page to page.

Actually, I will post just the first section of the technical details since it doesn't really reveal too much:

Technical Notes
The back-end flow of the SCC differs lightly from what it appears to be in the interface descriptions above.

Between each page change (i.e. from wizpage1 to wizpage2) the processing is actually routed through a validate fuse that does data validation every time the user clicks a navigation button that is not labeled as “previous” (no need to validate going backwards…only moving forward). The validate fuse controls all the flow by running validation checks, and then setting which page to redirect to based on the outcome of user selections, and data input.

Each of the interfaces listed above will be covered in detail here, and additionally a section for the validate fuse will be included.

Because the framework used for this application is Fusebox, there are certain processes that will take place on every page load, and do not need to be explained in each interface description. These include establishing a database connection, starting the session, setting the language variable for correct display of information, setting up the main template for the site, and basic Fusebox initialization.
main
From a programmatic standpoint, there is not much happening on this page of a dynamic nature (beyond language file includes). When the main interface is invoked several actions occur at the server:
1) A function called is made to display a demonstration help icon.
2) A module call is made to the help fuseaction to get some help content that needs to be displayed on the main page
The content is rendered for display.

Below main would be the section describing wizpage1, then wizpage2, etc. In this case, main really has nothing to do with the actually calculator data, and that is why it is so simple.

Wireframes
When I can afford the time, I do like to use very simple wireframes to demonstrate how an application will flow (or even just part of an application). I do this only on a rare basis though. However, Wireframing in general can be of great value when dealing with a client.

Bug Tracking
We have an in house bug tracker (webTracker) that I designed that we track our bugs in. It is not used quite as regularily as it should be (i.e. someone reports a bug via email, you know its a one line fix, so you go fix it and update CVS - no entry in the bug tracker). It does work though, and it may be the springboard for a more complex change request tracking system.

Software we use:
PHPEdit (www.phpedit.net) (I am biased but I think it is the best editor out there for PHP)
CVSNT (www.cvsnt.org) (www.cvshome.org for regular CVS)
WinCVS (www.wincvs.org)
UltraEdit(www.ultraedit.com) (me)
Textpad (www.textpad.com) (everyone else)
PL/SQL Developer (www.allroundautomations.com) (I am so glad I found this software)
Regex Coach (http://weitz.de/files/regex-coach.exe or http://weitz.de/files/regex-coach.tgz)(I don't use it, but others around here have)
Dreamweaver MX (www.macromedia.com) (actuallythe whole suite CFStudio, Homesite, etc)
Adobe Studio (www.adobe.com) (Photoshop, Pagemaker, Acrobat, etc)
MS Office (for spec docs, spreadsheets, etc)
MS Visio (diagramming)
MS Project (not as much as I should use it though)
ArgoUML (www.tigris.org) (I just wish it was possible to save an XMI file directly instead of all the hoops needed to jump through to get to it.)
Beyond Compare 2 (www.scootersoftware.com) (Insane value in this software - and for an insanely low price)
WS_FTP (I don't use this as much any more... Beyond Compare handles the FTP stuff better for what I need)
PuTTY (Google It!) (everyone should have this if they do any remote terminal work from a windows box).

I am probably missing another program or two... but oh well


Ok, I am running out of steam here.

Cheers,
Keith.

[lvalics]

For who are interested in CVS for Dreamweaver, I invite him to
http://www.grafxsoftware.com/product...reamweaver/22/

[Clio]

Really interesting thread !

For my opinion, team development is very interesting practice for any programmer, 'cause it gives us as much skills as we can get from each other.

In our company, we have team from 3 programmers, we have projects to develop to together ... but each one has it's own coding style, project structure, ... etc. Now we study to work in one solid team ...

The first step for us was setting up a CVS-server and discussing our universal principals for all new progects - structure, vars, funcs and classes naming, setting up internal discussion board.

Short period of practice takes a good results!

[lastcraft]

Hi.

I thought it might be time to reexamine these a year on. If I don't comment, then nothing has changed of importance (not necessarily a good thing).

2) Scripted roll-out.

We have done 50+ rollouts to multiple servers since then, I cannot even add up all of the time this must have saved . We have just set up a dedicated test machine that mirrors the live servers. This will take Jon Ramsey's Rephlux tool for nightly builds. This is now a high priority item as the larger CVS export and test times, combined with more servers, means that a roll out takes a while even though you can go off and make a cup of tea during this process.

3) Iterations. Our only management.

We have refined this into a varient of the Scrum backlog and also involve marketing and business development in these meetings. Basically we have a big bunch of index cards with task names, a breakdown of the task and the estimated time in ideal days and other resources. The stakeholders fight it out to get tasks into our (now three week) iteration. Very simple system and much more focused on the priorities of the business rather than the priorities of the developers.

I am starting to export this system to other ventures.

5) Unit testing.

Acceptance testing is really starting to take hold. We are grappling with a big legacy section of the site at the moment and wrapping it in course grained tests is the first step in getting control. SimpleTest was of course a spin off project designed for just this task.It's finally starting to pay it's way.

Also, if you use a section of code rarely, the acceptance test is a great starting point to drill down from. Much more of a specification and documentation tool than a test tool. If I were to start over, I would give this technique much greater prominence.

5) Stand up design sessions.

Environment really plays a part here. We never did move and our office is too small. Whenever we do short design sessions, the next bit of code goes very well, but we don't because the room doesn't lend itself to that activity. We are definitely moving soon. My rule of thumbs are now: have room to stand up, have plenty of whiteboards.

9) Scripted server set-up. Insufficient. We can build a server with a single script (MySQL, Perl modules, Apache, the lot) in one go, but it just doesn't work for updating them. Investigating an RPM solution, possibly using Ximian's Red Carpet or a modified Apt-RPM tool.

We now use RPMs and a modified apt-RPM tool. That was a good move.

10) Code docs. Marginal. We had a home brew comment parser that is just too slow. As a result it doesn't get used. We have for ever been mindlessly creating the comment blocks ever since. We are going to try PhpDocumentor after porting the comment syntax, but I would be happy to delete the lot.

We ported to PHPDocumentor and sure enough, no one looks at these comments either. The comments are starting to age as well. I am now completely convinced that if you have other mechanisms in play and experienced developers, this technique is obsolete.

11) Four day week.

Still do this. No change, but I just had to mention it again . Others...

We added a bug tracker, but it was too fiddly and got dumped. Right now our bugs/features are kept in the customer support system. This doesn't really work too well and we are looking again at a solution. From the customer point of view, these systems have to be completely integrated into the web site. As a result we will probably go with an upgraded support system rather than a separate developer system. We haven't solved this problem yet.

We do a lot of outsourcing and have learned some hard lessons. One of these is definitely communicate with acceptance tests. Puts discussions into much sharper focus and can save an enormous amount of time zone delayed e-mail discussions.

We have a small library of books. This is a great idea and a much neglected productivity trick. Why have developers twiddling their thumbs or scouring the net for some pattern when it could just be six feet away? If your employer doesn't allow you an amazon account, they are making a false economy. It also gives you something to look at whilst waiting for the automated roll-out...

The hardcore techniques we would never give up on are unit testing, pairing, shared ownership, refactoring and iterations.

So, is anyone doing things differently a year on?

yours, Marcus

[Darchangel]

I'd like to know how people in big companies are fairing.

big company? medium ~130 at last count. big for an seo firm, but not huge in the grand scheme of things
big development staff? not so much. ~10
big php staff? that would roughly be: me, myself, and i. and our other coders are all cf people (now you can see why i'm so far behind on oop)

[arborint]

Really excellent list. I would be interesting to see the differences between solo programmer, small group and large group practices. There are a lot of solo programmers in web development.

A couple things I would add:

- Live and Development sites. I usaually have live, staging and dev sites for each project. I have scripts to rollout/rollback code and databases. I also have scripts to copy the live DB to staging/dev sites so I can test on real data.

- I find I am using PHP for command line scripting more and more. I had used Perl extensively, but I find that all the classes I've developed support tool development as well as web development. This is a fairly recent development for me. I have converted most of my cron scripts to PHP as well. It just unifies development for me.

- Scripted server set-up is still a pain, but is scriptable to a large degree. I use shell scripts to compile Apache, PHP, etc. and use symlinks to allow rollout/rollback.

[been]

So, is anyone doing things differently a year on?

Since I also posted over a year ago, here goes:
(I think I fall in the 'solo webdeveloper' category btw.)

Use version control, I've done a long time (much too long) without it, but now I am more than convinced it is absolutely essential. Have planned to setup cvs this weekend.

Well, it took another week longer if I remember correctly, but have since then been using CVS
Considering moving to subversion, seem to hear nothing but good things about it.

Write inline doc for the unit tests, write the test code, write the inline-doc for the code and then write the code

bla bla bla, That changed to writing a short description of what the class is supposed to do, plus a short description of parameters in methods.
Most of the time I am the only person really dealing with the code and must say I've witnessed somewhat the same thing as Marcus: over time, the docs simply get out of date. In my case, the most ocurring sign of 'doc aging' is that there are more parameters documented than there are in a method's signature.
I think this is because I've began unit testing and I'm guessing that updating docs kinda upsets the 'test, code, test, code, ... refactor on green'-rythm.
All in all I'm also thinking of dropping doc comments, no docs seem to be a lot less frustrating than incorrect docs.

Writing test code has not yet, unfortunately, evolved into a natural habit for me

I wouldn't say 'natural', but it has become a habit, and it was a real eye-opener. And I'm not kissing your derrière here Marcus, but I really owe this to SimpleTest and it's author

Setup a basic bug-tracking system.

At some point a system is tested and ready to go, people I develop for have tested this system and approved of it, then it goes online.
Bugs that rear their head then, simply get reported back, I hunt it down, throw it in a test, fix it, deploy locally, customer checks and approves it, re-deploy.

The important part I've learned here (the hard way btw) is to talk intensively to who(m?)ever it is you are developing for, having an open communication whereby each party is considered equal, creating this "going step by step together" atmosphere. It's difficult to achieve, but whenever it happened, it was a great experience for both parties, and when it didn't, it was a bad experience for one of the parties, and most of the time that was me.

All this stuff, doing it purely by myself, takes such an enourmess amount of time that it scares me sometimes

Nonsense, getting acquainted with things like CVS and unit testing really didn't take that long and after a year, they have become an integral part of my development and I allmost can't imagine ever doing without them.

Got more into writing scripts to automate the tedious error prone tasks, but haven't got a tried and tested 'one click rollout' strategy yet
Use a develop and stage phase, for which I write rollout scripts (combination of shell and PHP). Production rollout is still not fully automated but for the moment, I can still handle it all. It is high on my priority list to get this worked out though.

Went back to school (evening courses - Programming, second year now), doing a lot .NET programming for the moment and liking it, refreshing to see things from another angle.

Most influential book read: "The Pragmatic Programmer - from Journeyman to master". Boy do I wish I had read that one sooner, really, really, let me repeat that: really, recommended! There is just so much good advice in that book, I've got the 70 tips compiled as a background on my second monitor and for now, I'm considering it my personal bible.

In fact, if I just copypasted those 70 tips here, I might have posted something interesting

[OfficeOfTheLaw]

Nice post marcus.

I work for a small company too, been the solo developer but now have another developer working with me. We've been given solo projects for awhile, but now we're finally working on a project together. It's a hard choice on how to best approach problems, and there's also the issue that while I'm an OOP type of person, the other developer is just getting into php.

Suggestions? We've been working on a system to process loan applications recently, we've put our heads together and had some rather good brainstorming sessions, but how do I phase this into development? I've always been a code first type of person, which gets dangerous on larger software systems. Even though we've been doing plainnning, there's times I'll just sit down and code something and see how it works, and at times I feel like I may write too much to do small things.

[josheli]

thanks a lot for reviving this topic, i was just about to ask in a new thread.

anyway, i work in a government agency of about 10,000 people spread over a wide geographical spectrum. i'm the sole developer (mostly) for this agency's website. we serve a few million pages a month to around a half million visitors. we offer a wide range of services and applications to the public and to internal users. as i mentioned in another thread, we've currently got around 35 "web applications" in use, beyond the general content of the site. some are simple 2 page surveys for the public, some are fairly large internal systems. all applications also have an administrative web backend.

i'd like to make clear that we provide a lot of very useful and helpful services.

i am not a part of the IT department, I'm actually in the Public Information department. i think this has a lot to do with the approach and perception to development. much is due to the fact that we do not control the servers at all. the server group sits in a locked room and hands us FTP accounts and phpMyAdmin. i have to get very creative to even do simple things like a database backup or produce web stats. i have a lot of automated command line PHP jobs running on my local PC.

It is 99% PHP/MySql development (1% Perl). Previously, it was an ASP/Access driven site, and much of my job in the last year has been to port the ASP applications to PHP. My boss does about 10% of the coding. We have another person who handles a lot of the static content, site maintenance (no coding), etc.

Best Practices? None.

Design: Occassional whiteboard sessions with my boss. I sketch things out with pencil and paper.

Source Control: A shared Windows drive. i've been asking my boss for months to allow me to set aside time to implement a source control system. this week i finally just set one up on my local PC, which means i now have code potentially in 4 places (local, shared drive, backup server, live server).

Testing: A backup server where we and our users do manual clickthroughs before we go live with an application.

Documentation: None, other than in the source

Refactoring: Almost none, maybe an 1 hour/month if i'm lucky. there's always too many new things in the pipeline

Bug Tracking: A user email to my boss, forwarded to me, a fix, a return email

Pair Programming: I often sit with my boss when he his stuck on something. It's not very productive.

the list of course goes on and on. i can see you guys wincing, sighing, wagging fingers...

i'm honest enough with myself to know that these "practices" are:
1. untenable in the long run
2. unproductive
3. not helpful for my professional growth

so here's my plan for the next year. if you've got any ideas, i would love to hear them.

1. source control - i'm not sure how i can make this work. i don't have access to install anything on our backup/test server. we can't run cvs/subversion off a shared windows drive can we?

2. testing - this is something i actually can implement, and hope to with simpletest, which i actually use on my personal projects. i'm not even sure what acceptance testing is.

3. refactoring - since i'm pretty unsupervised, i can allocate a couple hours a week to this i think, but i'm going to be judicious in where i apply it

4. iterations - hmmm. most of my projects are less than a month long, often much shorter.... so my iterations will be in hours or days?

5. bug tracking - i've never found a system that i actually use beyond a couple initial days, any suggestions?

6. pair programming - not really applicable

hope i don't get fired.

[MiiJaySung]

Interesting thread indeed.

I probably work on the opposite scale to Jeff here. I work in a very small company (Me + my boss). Both of us have sod all qualifications relating to computing (not even pre university stuff). In a way we have both evolved as hobbiests who want to move on and go further than the 'average' web design / web programming companies (We have something like 400 companies and freelancers in our town here). In order to do this, there is a lot more focus on the client and being able to do more "specialised" jobs.

Being a small, and very young company has probably given us a fast learning curve. Being 19, this is my first job I have ever done, and both of us have no experience with team work. As a result it has been a very interesting past few months for both of us.

* UML Diagrams. Like Marcus said, prove to be good for initial plans. One can quickly identify possible problems as class diagrams can makes you think about how you break stuff down into classes and the communication between them. Generally, this is done in paired fashion (We don't use CRC cards, so this almost works in place of it). Like Marcus said, as things evolve UML gets out dated. Squence diagrams also can be handy when paired with class diagrams as class diagrams only show part of the picture. I often don't bother with these though if we both work on the class diagrams. Class diagrams certainly help me a lot when looking at other peoples OO code as I can quickly see roughly how things are put togerher without jumping around through loads of src.

* Code comments - This is a must for explaining algorithms and why one has choosen to a particular approach (for instance commenting complex sets of if blocks if they aren't very human readable), so other programmers know. The other thing is we use // comments to put any comments for things like "to do's" or to state when code will need changing again soon. Where as /* */ comments are used for long-term comments that explain how things work. Comments are a must as these illustrate thats that a class diagram doesn't show. Doc comments are used, although this is normally left nearer the end when code is in a more solid state, otherwise things go out of place.

* Semi Test driven design - We haven't got round to doing this properly, but as we code things, we do slap up in another PHP file some basic way of testing certain chunks of code. One day I will get round to implementing this properly, but I need to wait until I have time to investigate this. This will be early next year. Even having to odd piece of test code here and there does help save some time.

* Some paired programming helps. As a two man company we still do lot of stuff by ourselves. However ensuring that design work is done together ensures that tasks can be delegated off without too much hassle. paired programming helps a lot when fixing the odd bugs or trying to work on more complex aspects of a project. This also helps when you're very tired :-P

When I first started work we did not have a office server box, and we used Dreamweaver. This was a nightmare. I hated the UI, and it did not have have good enough features to deal with team work where code is shared. Getting good tools makes a lot more difference. We now use textmate and jEdit. The office server lets us us share code instead of working on localhost. Because there is only two of us, we just state what files we work on verbally. It also allows us to work from home, and let clients see work at various stages in development as we work on it. Because this is setup up in a similar way to our Rackspace server we can use this to trial different setups before working on the main server. Use of VMware for this sort of work helps us test setups with the ablity to roll back if something doesn't work. Getting subversion to be setup is on my new years to do list. As verbally stating what we are working on won't work if we employ more people as our 'verbal system' will break down! If we need to rollback, we currently depend on backups. Not ideal, but this is rare anyway.

Things we need to work on that will help ...

* Proper TDD

* Better sharing of code and versioning. Sometimes I get allocated work and I have have spend a while trying to explain bits to my boss. Working together more does remove this barrier. Shared knowledge removes barriers and allows more flexiablity. In turn this demands better versioning, and it will be easier to work from home. This is our biggest set back at the moment.

Another thing I'm learning is the need to do things throught iterations. This is my biggest weakness. I try and do everything in one big chunk and end up continously changing and faffing about instead of dividing things up and and allocating new features and changes into a separate iteration.

One thing I have learnt since starting work is that spec docs and working closely with the customer is important. One of client we used to deal with is always changing the specs and never breaks thing down into iterations. They always expect everything yesterday and the pressure has meant existing code has not been tidied up (this is old proceedural code so not really refactoring). The result is a project that drags on and is way out of budget / timescale. The fact we have to work to the clients daft hacked DB schema means that the database is messy and could be factorised down a lot more. Now we spend more time discussing what the client wants as well as trying to find out from the client what sort of future requirements could so we can ensure there are more in the way of "flex points" in any parts of the code that are very likely change. Planning out iterations and realistic timescales is a lesson we are learning from, though it is hard to predict some "technical issues". (for instance getting javascript and CSS to work as we always run into unpredictable querks with IE. Developing on the mac doesn't help imo as IE is mainly a windows thing (however Mac IE and Windows IE 5 are totally different, thus adding a new dimesion of hair pulling stress to this rather frustrating aspect of development). Functionally specs are a good way to ensure clients don't expect us to put in random features, and prioritise aspects from the development. It also helps enforce the iterative approach.

Communication with the client also allows you to highlight issues with the clients and make them realise what parts of the project might take time or are complex, and just make them generally aware of what is involved in the development process.

We always avoid offshore development. I don't liek trusthing other peoples code, not to metion inconsitancies with coding standards, and general approache to programming. Also, few PHP programmers are well disciplined. Communication barriers are an issue.

All in all roughtly in order of best results ....

* Working closely with clients (drafting functional specs / use cases etc)
* Shared code ownership / paired coding / local server / CVS / Client logins to see work in progress (In turn implies the need for CVS or SVN soon)
* Coding standards
* Iterations

All in all, these practices are all linked to each other. i.e. functional spec helps break down a project into iterations and develop good deisgn. Coding standards and version control are a result of paired programming / shared code owner ship. refactoring and iterations go hand in had with each other, alogn with TDD. It's clear one leads on to another to me.

Things that don't work.

* Dreamweaver and annoying IDE's
* Working on localhost, or always using FTP upload in dreamweaver.
* Specialisation in areas of a project (due to lack of communication)
* Lack of spec to work from if clients requirements are always on the change. Also everyone needs to know the bigger picture when it comes to developing a project, so specs that are developed as a result of team interaction is a must)
* Unrealistic deadlines (doesn't give time to learn new skills)

[Austin_Hastings]

Marcus,

I make a living as a configuration management consultant, so some of your list is bread and butter to me.

Specifically:

1- Everything is checked in first.

2- Anything that is done twice is scripted.

3- Anything that can't be verified must be specified.

I'm a big fan of "dashboard" applications. At my current gig, I've got the client using CVS, Ant, CruiseControl, a project wiki, buzilla, and automated integration builds & testing.

The client is actually my first "real" employer from about 15 years ago. The coding standard I learned here I'm still using, although the client has started to fall off the bandwagon after too many staff turnovers. I've been working on using CodeCheck to fix that problem, though.

Anyway, the client is a "small" site, but I've got a cooperative manager and we're using "big" practices. The result has been that a tiny team of employees and a small surrounding group of consultants has been able to build "infrastructure" applications that give us HUGE leverage.

I have never seen "docblock" comments as an effective tool. Naturally, I'm now considering recommending them -- the customer releases OEM source code, so it's actually important for the coders to be able to update the documentation.

The application of the three rules above causes some consternation at first, because you suddenly find yourself looking at automating or documenting things you aren't used to thinking about. But after the first hundred times I raise the issue, people get used to thinking in those terms:
"Vacation time? I can't afford to code a system. I'll write up a policy doc."

The local manager is very resistant to UML -- I guess that's the price I pay for him having so many nice features in other areas. He's very willing to accept "intermediate language" though, so he might not realize that some of the XML he's been seeing has actually been XMI.

The "automate everything" approach earned me my favorite quote a few weeks back, "I keep talking to you and hearing about 'The Shining Future', but this weekend I had to [...] and it only took 10 minutes! This is 'The Shining Future'!"

=Austin