How fast can your car go

0-60, is a metric used to determine how long it takes a car to get to the top speed. The better the car is tuned the the lower the time to reach 60 mph. I was wondering on the weekend if this metric could be used in software development or more accordingly in the usage pattern of a company implementing a solution. Instead of 0 to 60 mph, why not 0-60% efficiency using the CRM, or EPR or some other software. So how long will it take your team to get 60, or 80 or even 100% value from your chosen software package. I suspect 100% is not a realistic target, but is 80% and if it is, what does it take to get there.

Talking with a business partner about the use of company internal developers vs. external BP based SalesLogix developers I wondered how long it would take for the internal developers, the ones that work for the end customer, to become 60% efficient at creating the customizations needed for the business to succeed. Also given the current economic climate where the internal developers are asked to do more in their already busy workday, how much of their focus would be on learning the technologies. These constraints can slow down the ability to reach that 60% efficient goal dramatically.

Couple the friction of getting the solution completed internally (technology, resources, capability) with the need for the business to get the solution in their hands, the initial perceived savings of in house development may actually be out of grasp. With a car, you can tweak and tune, and if needed be change the exhaust, tires, and even the engine the same cannot be said with a developer. When there is a business running on the software or solution it can better to couple with a partner, or developer who already has a tuned engine to aid in winning the race.

Technical Debt

Technical debt is that chore that developers owe when they go back into old code. It’s the process of cleaning up or right sizing the code that they wrote to make it more readable, efficient and remove any dead code that is not longer in use. In my day to day I jump from project to project and recently I have re-engaged in a project to fix some defects and potentially add some little enhancements. I also consider that these times of re-engagement the opportunity to pay back some of the technical debt of deliveries gone by. Yesterday was one of those days where I was reacquainting my self to the code while offering up some refactoring. The funny things is even though I have been and software developer, engineer, architect and what ever other hat I wear for so long I still found my self once and a while feeling like I had a little bit of vomit in the back of my throat while reviewing the code. I am every grateful at the pliability of code and so thankful for Refactor, or R# for allowing me to easily and efficiently re-architect pieces and parts and a very forward and pragmatic way.

Question is, when you look at some of your old code, do you leave with a warm and glowing feeling, or do you feel a little sick and ache to be able to have a bit of a do-over. I suspect if you are a professional developer the later is the more realistic response. I really believe it is in all of our natures to say, if I knew then what I know now, or shit … if I just do this, or this this thing would work better, be less coupled, provide a better experience.

Its the trade off between time, money and resources, and going through the development cycle and initial time that  I suspect that will always leave us knowing that we can do even better given more time, resources.

Yesterday for me was a great day for handling technical debt, though it was long at 14 hours, by the end of the day I was happy with what was accomplished.

Entity Pages and XML Schema issues

I have been working with a SalesLogix business partner on a project for a while. A few nights ago I got a query from their developer with regards to an issue that they were having. While trying to implement a main view in the web client (known as an entity page) when they would navigate to the page and try to add a group it would fail with an nice and friendly message stating that the XML Schema was missing.

I have heard in the past that there had been some problems with the group builder functionality and started to investigate down that line. I even followed up on the blog provided by Ryan Farley at  CRM Developer . Finally I contacted some of my sources to understand how the feature was working and if there was some way to force a schema rebuild. Initially yet knowing the true issue I was told that I could force a rebuild of the schema by updating the datacode field basically reversing option 3 in Ryan’s post. Thinking that this was the right course of action I did so and unfortunately the page still would not render correctly.

I then dug a little deeper into the page’s setup to see if there was something amiss. In so 2 items came were identified as issues.

1. The page did not have a configured entity type

2. The page’s alias was not the same as the entity type it is hosting.

So the first issue was the big one. Given that the entity type was not set there was no way the group builder functionality could determine the base table/schema to resolve to. Once I set the page type correctly it was now possible to display the list view grid and build queries in the client.

The second issue was identified after enabling a column as a link column and trying to display the detail page. Since the internal resolution of the URL for a link is based on the entity type name if the page is no named the same as the entity it cannot be located. Once I changed the alias the page’s details were now displayable.

So when you make an entity page make sure that you set the entity type, and also set the page alias (name that the page is generated as) to the same name as the entity.