Copy 'n' Paste

The most common programming technique I use is copy'n'paste of code. It is a skill that needs development, even though intellectually it is frowned on. To be good at copying and pasting code, one needs to be able

•  to recognise code similarities so that a good source can be located
•  to recognise the parts of the copied code that lend themselves to extensions or adaption for the desired solution
•  to then find commonalities among the copied and source code that can be extracted to create new structures.

Coding from this persepective is a construction exercise, not a logic exercise. Most of our training assumes that it is a problem solving exercise - analyse, design, code and test. Whereas the copy'n'paste technique takes the approach of throwing code together based on example, then addding and removing code until the final result is recognised to be correct.

This reverses the understanding of the programming exercise to be

• continually define the result that is required and know how to recognise that it has been achieved
• work backwards asking what are the needs to get this result, using the simplest and most convenient way possible - this may be just copying code
• continually cleaning up the work that is done

This workflow changes the interactions between the developer and the client. It is at heart, the agile approach.    

Where does the time go

Over the last few days, I have been helping verify some software for an new production environment.

In the end only minor changes had to be made to the code. If I was familiar with the code base and the configurations, it would have taken at most 2 hours - but it took 3 days to resolve all of the problems.  This was a perfect example of where much of my effort, and no doubt, other support effort goes these days.

It was so unproductive and frustrating. This experience is becoming more common as most of my work is either direct support, or enhancing existing systems.

The cause is fundamentally a management problem. In general, the work that I do is triggered by a business request (in the form of a change document), that must be tracked via many redundant procedures in an idealised development life-cycle. There is no investment in keeping the code base clean, and ensuring that the internal structures are well factored, and understood.

By and large, the code base is "write only" code. By this I mean, the code is largely only well understood by the author of the code, and then only when it is fresh in their working mind. This problem is excarbated by the fact that the code base is a collection of text written in  variety of  forms and using a collection of technologies that embrace the .Net Web development. 

Where was the time lost - all problems had to be discovered. They could not be predicted. In development the code works fine, and thus gives no hint to the implementation problems

• understanding of the essence of the implementation technology
• determining a variety of missing configuration settings
• no good error trapping and reporting as problems arose, thus masking the original problems
• introduced bugs in the adaptive code, initially masked by the configuration and error trapping problems
• painful code-debug lifecycle as the problems related to transitioning developed code to a simulated production environment.

This can only be improved when an investment in effort to improve the code base and ensure that the structures follows the needs of the application. I do not see this as forthcoming. These frustrations will be repeated. 

Skills to Develop

I am attempting to expand my skills in using C# in the latest .Net technologies. The daily grind of work distracts from this purpose.

This is an exhortation to practice the following skills daily

• Linq in its various incarnations
• WPF and Silverlight
• Data Handling via LinqToSql and Entities

I see these as the fundamental skills for developing .Net applications.

I will try to comment on some of my efforts in this regard. This is an attempt to keep focus.

Life-cycle frustrations

My work day is now lost in the software life-cycle. By this, I mean my time is consumed by the procedures and the tracking of same. The actual time I spend on development or support that is delivering code is now down to about a maximum of two hours a day.

The remainder of the time is lost in a bad tracking system, following and documenting aspects of the procedure, or wading through bad code in an attempt to understand it. The issue is how to overcome these problems and spend more time on actually delivering code.

Many of these problems are arising because there are so many roles in the IT group that only have a tangential interest in developing software, and they need reasons to justify there existence. These reasons claim part of the developer's time. Each has a small claim for existence. However, by forgetting the reason for the development, we allow these claims to become much larger than they need to be.

This for now is the frustration of my day. So often, I ask myself if I have achieved anything. The answer is really - no. But I keep the monkey's off of my back because the paper trail is met and on time.

.Net Exercises

I am currently working with the .Net technologies. My workplace, though, is slow in moving to the later versions, and as such, I start to feel that it is easy to get out of touch with some of the ideas and practices. I will attempt to use this blog as a motivation to working through some of these newer techniques, and documenting my efforts and understanding.