This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: Software Development Until Done
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
I am touching some code at the moment from a past employee. I cannot say the code is bad, nor that he is at fault. But, the result of half cooked code, is that it takes longer to understand, longer to set up on a new machine, longer to debug, longer to find and fix errors.
I have some brains, but still after 4 hours of delving into a project that utilizes a web service, DotNetNuke and some other projects, could not find the database, then source was checked out, code was duplicated in places (not sure which section was to blame), configuration files named, "development.config", "web.config", "test.config", "x.config", "y.config" made it impossible to find out which things was expected. I have yet to find a single paragraph on what was intended by certain portions of the code.
This is still on going, driving me crazy. I will probably be busy with it for a few days now.
If you think this does not apply to you, you are wrong.
Do you write code until it is done?
Now that question is loaded and very indicative of our current situation in software.
What is "done"? It is has no common definition or understanding. You could be done, and I could be done, but Jeffrey may have more to add. "Done" has so many interpretations. Is it done, because it works? Does it work now? what about later? Can code that is done now, be undone later? How done is done?
In the kitchen sense, it means different things to different people. Unfortunately most code in the business world is undercooked.
If you write code, that is based only on features, or on a level of it does what was asked of me, you are under cooking the code.
Call to Action
To cook your code longer and better, please do a bunch of these things on that code you are working on now. You should try to leave code as if its the last time you will see it. You should leave code that you would want to find.
1. Delete code that does not apply, config settings that are old. Anything that is historic. If you don't have source control software, then move those things to another directory. But make the actual live code void of historic bits.
2. Spend another hour or two refactoring that messy module or class. Do it now. Don't leave it.
3. write a small readme.txt on the running environment. The names of the projects, dependencies, 3rd party installs, folders, configs, xml, services. Anything that is required, that you setup, configured and changed to get it running. Write the process and environment settings down and save it in a readme.txt in the source.
4. Copy all the code to another computer, and get it running there, using your readme.txt.
5. If you haven't got any unit tests, start now. Write 10 straight way. Write another 10 every day, until you catch up, or begin to get somewhere close to where you should be.
6. Once you have tests, or added more, refactor more. If it is hard to justify to your manager, spend 2 hours after work, refactor some source and then show your manager the difference between the two sources tomorrow. (and get him to read this)
7. Write a set of Unit Tests that prove the readme.txt file. It checks the environment. And if it does match, all the tests pass, the next developer to look at your code, will be more grateful.
8. If there is a more experienced developer in your midst, ask them for some advice on making your code better, neater or simpler. And really think about what they say, to help you improve.
9. Open a code file in your source control software, someone else has written, and see what negative comments you can make on it, not to diss them, but to learn what you can do to avoid others saying those things about your code.
10. When you think you are done, start again, spend another day or so cleaning up, more. You will most certainly have forgotten something.
If you cannot justify the time during a project, do it after the deadline. But do it.
Why did I say you were wrong to think that it does not apply to you? because it applies to everyone. Our code is never perfect, no matter who we are. We need to constantly strive to make it better.
Previous Topic
