Software and the Auto Industry

Many years ago I was wondering why personal computer (PC) pricing was dropping and car pricing was rising. Several news articles explained the difference, but I still did not get it. I never thought much about it because I did not want to reboot my car at 75 miles an hour on a highway.

One day though I ran across this information from http://www.teslamotorsclub.com/showwiki.php?title=Model+S+software+firmware+changelog that has a change log.  I have many change logs for our U2logic application software and our XLr8 tools software.  I know what those are.  I own two cars. I know one of those cars has about 7 computers. But never once have I had the dealer call and say I need a software update.  With, I’m guessing here, millions of lines of code running these computers why have I not ever had an update?

Maybe the auto industry, except Tesla in my example, thinks you bought the car or truck as is and you don’t need and update. Obviously, the government will not let a safety update be withheld, but all else is up to the auto company you bought it from.

Let’s, for example, buy a car without cruise control, automatic door locks, and dual air conditioners for you and your seat mate. A few months after you bought this great car, you want the prior mentioned options.  Guess what you are out of luck whether by design or by lack of forethought.

Maybe if all cars were built with all of the hardware installed and the software controlled the use, then you and I would have to pay for those options just like we do with our desktop software.  With the reduction of components that go into the car by using software to control those options, there would be some price reduction but nowhere what I would like.

Next time you are driving to work think about all of the functions you are using to get from your home to work that could be computerized.  Or maybe I will be calling you from my “Johnny Cab”.

Bug Tools not in U2 Shops.

In U2 world (Universe, Unidata, and D3) very few of us use any bug related tools.  Maybe your IT department uses a spreadsheet for all outstanding tasks, or maybe you use email from users to fix and change software.  At U2logic many years ago we thought we would create our own tool.  We definitely were suffering from NIH (not invented here) mentality.  Our tool looked great because it was web based, but it suffered from a lack of vision of what was important.

One of the more important components was email feedback.  Whenever a task or problem is requested of you or your programmers, it should be visible to the entire staff.  That way if someone is on vacation or it is after hours then many eyeballs can and will be watching the bug tool queue.  When status is changed on your task or problem, the user that requested the task or pointed out the problem should be emailed with that notification.

Another important component that was missing in U2logic homegrown version was the ability to upload pictures.  We did not even comprehend how important this was to users.  Some users would spend hours designing a report or web form and we would either not pay attention to it or we would do our own thing for whatever reason.  With a great bug tool programmers and users should be able to upload screen captures, spreadsheets, text documents or PDF’s, so that everyone can visually see what is wrong or what direction they would like to go.

One component we have found that users and programmers must have is ability to edit and re-edit their comments.  We cannot tell you how many times some of programmers cannot spell and that makes the bug tool and the issue look bad.  We have found that users have sent us off on tangents because of bad descriptions of the problems.  Now, they still have bad descriptions but we can edit them back to reality.

After we abandoned our in-house tool, we went to Bugzilla which was very good but not well received by our users.  We have dropped Bugzilla for JIRA last year which is a paid tool unlike Bugzilla which was free.  Whatever tool you decide to use make sure it fits within your organization and those you support.

Finally a "real" editor for D3

OMG, what is this flip the buffer thing.  I am ported back in time.  Yes, that is what is happening.  I have to edit a program in D3 and I forgot about flipping the buffer to see the changed code.  It cannot be 1984 again.  I did not like it when I first experienced D3 but it was not called D3 back then.  What was it called?  Maybe it was called OA or R83.  Why should I care why is this editor so archaic?  This is just a dream.  I'm waking up now...

U2logic has created a full screen editor using the open source program Eclipse IDE for our D3 programmers.  You can experience continuous compile of your D3 code.  You can have a local history of all your changes to each program.  You can have highlight reserved words that can be any color that Eclipse supports.  You can edit D3 programs from you Mac or Windows work stations.  You can see compiler errors via the Marker window by line number.  You can see compiler error via console window.

Within Eclipse there is support for source code control for D3 via mainstream technologies like GIT, SVN, Team Foundation, and others.  If you have a particular source code technology you like, they will have built an Eclipse plugin to access source code server.

Over time has we get going we will add the ability to copy from D3 to U2 and from U2 to D3.  This will make porting or moving data from system to system pretty easy.  We have use our copy and paste technology to copy between Universe and UniData for years.  Our copy and paste technology allows us to copy data from server to server faster than most other U2 products saving you time.

Many D3 customers have already ask us to port many of our other tools to work with D3.  We are prioritize them now and will be adding them over the next many months.  Thanks to all of our beta testers for their valuable input whether it be a bug or a suggestion.