Hey, it's been a while. This site is still active. I just don't seem to have much to write about. I still work in software. January 2017 marked 20 years doing this work. It's a pretty good career all in all. The pay and benefits are good.
Back in late 2015 I switched jobs and joined my current employer. It's pretty good here, and it has been a positive change. After RIM ended abruptly in 2014, my previous employer gave me a job when I was out of work in the summer of 2014. I appreciate them for that. It was what I expected and I don't have anything bad to say.
When I joined my current job the initial plan was around factoring out a piece of a large monolithic Java application so that it could be called from a .net client. As things turned out I pretty quickly ended up working on the .net side. There has been a smattering of Java here and there since then but primarily I've been working in .net and C# for a little over two years now.
I'd never done anything in C#, .net, or Visual Studio before. I'd heard some good things about .net but it was new to me. So at this point I have about 4,000 hours in on the Microsoft stack. It does make a difference being at it this long. Still learning and still not quite mastered. 6,000 hours to go I suppose. Though working with it for several thousand hours does make a big difference in proficiency and speed.
The .net stack including ReSharper is really quite good. Really well thought through, powerful, and easy to build applications with. Coming over from years in Java, the whole developer experience from C# to Visual Studio, to the .net libraries, it has been a very positive experience. C# is an excellent programming language. Powerful and well thought through. And LINQ is just incredible, and built right into the language, the intellisense.
Java and Eclipse is a great developer experience too I will add. I'm not going to declare a winner, both approaches are very well done and developer friendly.
I've done a lot of Web stuff with the .net implementation of MVC. And the Microsoft take on MVC with Razor is an excellent implementation. Everything is just there and just works the way you would expect. Microsoft really has worked hard on this and done a great job. I'd never really understood MVC before and now I've seen it done right it is a great approach to the Web. It was a great decision to have MVC right out of the box as a first class Microsoft module, it was very wise differentiator for Microsoft to own the MVC, instead of leaving it to the whims of third party vendors or open source for better or for worse.
Also I've worked more with the SQL Server database the last two years. Mostly Oracle over the years before coming where I am now. I've gained a lot of respect for MSSQL and SQL Server Management Studio. I didn't know much about MSSQL, but I will say it's a great database and does a number of things very well.
Friday, May 04, 2018
Friday, September 23, 2016
The 5 whys and escaped software defects
At training recently there was some discussion about using the Toyota "5 whys" line to get closer to the root cause of problems. Though Toyota wasn't mentioned. There was a bit of context around software defects and trying to trace back "further", so that in addition to fixing the immediate problem, find and fix more systemic issues that cause some categories of defects to recur.
it got me thinking a bit. In the past such as at SupportSoft there would be discussion and even tracking and measurement of "escapes", that is defects that made it into the field and were first reported by end users. So the error was missed by all of developer testing, code review, test automation, and the QA test team. I'd always found it strange that all of the focus and serious face talk about escapes was on the test team. The escaped defects were always blamed on QA for "missing" them in their test plans.
We never did further analysis to trace defects back further into the development team or individual programmer who checked in code that didn't work. I wondered why was the "blame" always on QA for escapes. They didn't write the code that didn't work. Oh well. I'd say the "pinning" of escapes on QA is from a mentality where quality is something that a test team either adds or fails to add as the final step in a software development process.
With 5 whys, things change in a more positive way. QA becomes a link in the chain, however if there are escapes then the entire team is accountable including original developers who checked in code that ultimately errored in the field. There was a chain of events that led to a runtime error in the field and QA is one link in the chain.
It's a new mentality, different than other places I've worked. Before it was understood and accepted that defects are a natural, unavoidable byproduct of advancing a software program. Development delivers code with defects, QA identifies the most important defects, development fixes them, dev/QA iterations occur, and everything moves forward and code ships to production.
With 5 whys we implicitly reject this silo model that code thrown over the wall out of development is expected to also include defects for testers to identify. With 5 whys and root cause the expectation becomes far higher initial quality out of development, with few or no defects, and far fewer iterations where software is "sent back" from QA to development for rework. Also there's more of a team approach to responsibility for quality of code delivered into production. Defects are owned by the entire team, they aren't something that testers either find or fail to find as the final step. Quality becomes more pervasive and end to end.
it got me thinking a bit. In the past such as at SupportSoft there would be discussion and even tracking and measurement of "escapes", that is defects that made it into the field and were first reported by end users. So the error was missed by all of developer testing, code review, test automation, and the QA test team. I'd always found it strange that all of the focus and serious face talk about escapes was on the test team. The escaped defects were always blamed on QA for "missing" them in their test plans.
We never did further analysis to trace defects back further into the development team or individual programmer who checked in code that didn't work. I wondered why was the "blame" always on QA for escapes. They didn't write the code that didn't work. Oh well. I'd say the "pinning" of escapes on QA is from a mentality where quality is something that a test team either adds or fails to add as the final step in a software development process.
With 5 whys, things change in a more positive way. QA becomes a link in the chain, however if there are escapes then the entire team is accountable including original developers who checked in code that ultimately errored in the field. There was a chain of events that led to a runtime error in the field and QA is one link in the chain.
It's a new mentality, different than other places I've worked. Before it was understood and accepted that defects are a natural, unavoidable byproduct of advancing a software program. Development delivers code with defects, QA identifies the most important defects, development fixes them, dev/QA iterations occur, and everything moves forward and code ships to production.
With 5 whys we implicitly reject this silo model that code thrown over the wall out of development is expected to also include defects for testers to identify. With 5 whys and root cause the expectation becomes far higher initial quality out of development, with few or no defects, and far fewer iterations where software is "sent back" from QA to development for rework. Also there's more of a team approach to responsibility for quality of code delivered into production. Defects are owned by the entire team, they aren't something that testers either find or fail to find as the final step. Quality becomes more pervasive and end to end.
Thursday, September 22, 2016
Five year plans
I've just done a training session. It was pretty good. The instructor made one point that was interesting. He felt that making a personal where will you be in 5 years plan was pretty pointless.
Thinking about it he's basically right. There's no way to project what will happen that far out and things we have no control over.
I thought back 5 years to September 2011. At that time I was with an UCCDI team as part of the blackberry platform group. The platform was about 1200 people total. since then this is stuff that happened that would have blown any 5 year plan out of the water
One day in fall 2011 we came to work and platform had been dissolved and UCCDI was no more.
Sorry after UCCDI was assigned to some existing team called Devops. It was quite a different culture and I was a misfit on that team despite working extremely long hours during the BB10 death march.
Luckily I escaped Devops and was able to switch to BlackBerry ID server at the end of 2012. That was a pretty good run with bbid server.
By the end of 2013 the Halifax bbid server team was attritioned down from 5 people to 2 and the team was dissolved. Me and the other Halifax guy were assiged as lone remote members to Ottawa sprint teams. In June 2014 there was another reorg and I was laid off from rim. That sure wasn't in the 2011 plan.
Luckily, shortly after rim ended I caught on at CGI and had a successful year and a half run there. Nearshore offshoring for a global European investment bank. It was good to be a senior again and have some status and actually write features.
Then late 2015 I caught on at ResMed where I am finishing up my first year. I also switched from Java to .net. I hope this can continue long enough to review what actually happened in the next 4 years here. It's good here.
Still to my point. from September 2011 to now a number of major things happened any of which would have blown out any 5 year plan. The same is true of a 2006 plan at SupportSoft when the future was to leave for RIM. A 2001 5 year plan at PRIOR could not have accounted for the xwave takeover, going to Core, the SupportSoft takeover of Core Networks.
So I agree in tech 5 years is too long and too much will happen. You just have to be able to adjust and deal with and advance yourself in whatever will unfold.
Thinking about it he's basically right. There's no way to project what will happen that far out and things we have no control over.
I thought back 5 years to September 2011. At that time I was with an UCCDI team as part of the blackberry platform group. The platform was about 1200 people total. since then this is stuff that happened that would have blown any 5 year plan out of the water
One day in fall 2011 we came to work and platform had been dissolved and UCCDI was no more.
Sorry after UCCDI was assigned to some existing team called Devops. It was quite a different culture and I was a misfit on that team despite working extremely long hours during the BB10 death march.
Luckily I escaped Devops and was able to switch to BlackBerry ID server at the end of 2012. That was a pretty good run with bbid server.
By the end of 2013 the Halifax bbid server team was attritioned down from 5 people to 2 and the team was dissolved. Me and the other Halifax guy were assiged as lone remote members to Ottawa sprint teams. In June 2014 there was another reorg and I was laid off from rim. That sure wasn't in the 2011 plan.
Luckily, shortly after rim ended I caught on at CGI and had a successful year and a half run there. Nearshore offshoring for a global European investment bank. It was good to be a senior again and have some status and actually write features.
Then late 2015 I caught on at ResMed where I am finishing up my first year. I also switched from Java to .net. I hope this can continue long enough to review what actually happened in the next 4 years here. It's good here.
Still to my point. from September 2011 to now a number of major things happened any of which would have blown out any 5 year plan. The same is true of a 2006 plan at SupportSoft when the future was to leave for RIM. A 2001 5 year plan at PRIOR could not have accounted for the xwave takeover, going to Core, the SupportSoft takeover of Core Networks.
So I agree in tech 5 years is too long and too much will happen. You just have to be able to adjust and deal with and advance yourself in whatever will unfold.
Saturday, February 27, 2016
Design Patterns by Gamma Helm Johnson Vlissides
I've finally got around to reading Design Patterns after all these years. I've known about the book for some time. I remember back at Core Networks in the early 2000s we switched to Java and kickstarted it by hiring in a Java team from the local market. They would have these what seemed like eerie stand up meetings each day filled with all these pattens they all knew about and constantly referred to.
Maybe, like Java, since that initial burst of excitement it's all just settled in and we just find it handy in our everyday software lives to get things done. It's pretty much expected that anyone in software is familiar with it and I was a bit remiss leaving it this long. I wish I read it 10 or 5 years ago. Well now I have and I'm glad I did.
The book is well written. 23 patterns is just the right size grouped into creational, structural and behavioral areas. The authors favor composition over subclassing. Still they also like abstract classes. A common theme is that introducing one level of indirection can open up powerful design possibilities. In the final pattern, Visitor, they permit themselves to show off a bit with double dispatching, taking the abstract class concept to the next level in an elegant and understandable way.
It's remarkable really this book was published in 1994. The era of DOS and Windows95. Still it's as useful and relevant today to use in C# and Java and iOS as it was then with developing for Win3.1. It shows how well written the book is and the skill of the authors. The authors are truly top notch designers.
Maybe, like Java, since that initial burst of excitement it's all just settled in and we just find it handy in our everyday software lives to get things done. It's pretty much expected that anyone in software is familiar with it and I was a bit remiss leaving it this long. I wish I read it 10 or 5 years ago. Well now I have and I'm glad I did.
The book is well written. 23 patterns is just the right size grouped into creational, structural and behavioral areas. The authors favor composition over subclassing. Still they also like abstract classes. A common theme is that introducing one level of indirection can open up powerful design possibilities. In the final pattern, Visitor, they permit themselves to show off a bit with double dispatching, taking the abstract class concept to the next level in an elegant and understandable way.
It's remarkable really this book was published in 1994. The era of DOS and Windows95. Still it's as useful and relevant today to use in C# and Java and iOS as it was then with developing for Win3.1. It shows how well written the book is and the skill of the authors. The authors are truly top notch designers.
Saturday, March 07, 2015
The IBM Fungibles
I heard an interesting word lately with regard to IBM and downsizing. The term is fungible. Per the LinkedIn post an IBM fungible is "someone on their bench who had similar qualities to other employees."
I guess that's an interesting way to put it. It does describe it pretty accurately. Someone who, if they suddenly vanished, either wouldn't be missed or could be replaced with an equivalent "off the street" very quickly with no meaningful loss in output.
the fungibles are fine. they get things done. it's important to keep in mind their billable hours generate the exact same revenue and profit as the key non-fungible people.
so who are the fungibles? maybe it's another way of stating the 80/20 rule. 20 percent are the key contributors who the firm is keen to keep on board and keep happy. the other 80 percent are fungible, can be freely interchanged with no difference. they can be laid off and there are essentially an unlimited number of replacements who can be instantly activated if needed. or to use my earlier 4 in 17 observation, the fungibles are the rest, the 13 in 17.
of course there's no plan to let 80 percent go. that would be crazy. however IBM believe some clump of the 80 can be safely let go in a layoff and things will just continue pretty much as they were and previous levels will quickly be reached again. they are probably right.
I guess that's an interesting way to put it. It does describe it pretty accurately. Someone who, if they suddenly vanished, either wouldn't be missed or could be replaced with an equivalent "off the street" very quickly with no meaningful loss in output.
the fungibles are fine. they get things done. it's important to keep in mind their billable hours generate the exact same revenue and profit as the key non-fungible people.
so who are the fungibles? maybe it's another way of stating the 80/20 rule. 20 percent are the key contributors who the firm is keen to keep on board and keep happy. the other 80 percent are fungible, can be freely interchanged with no difference. they can be laid off and there are essentially an unlimited number of replacements who can be instantly activated if needed. or to use my earlier 4 in 17 observation, the fungibles are the rest, the 13 in 17.
of course there's no plan to let 80 percent go. that would be crazy. however IBM believe some clump of the 80 can be safely let go in a layoff and things will just continue pretty much as they were and previous levels will quickly be reached again. they are probably right.
Friday, January 16, 2015
using Oracle REPLACE() function to generate Java unicode escape codes
On my current project the UI is a corporate web app. The user base will be global and the supported languages at this point will be English and some Western European languages. The localization setup is a standard Java messages.properties, with per-language messages_fr.properties for French for example.
The developers tokenize the UI screens and put the English content into messages.properties. an external team delivers the translated tokens, which development then puts into the messages_X.properties to complete the process.
With the Western European languages there are sometimes non-ASCII characters with accents or whatnot from the translators. In the .properties files I wanted to convert these accented and non-ASCII characters to \u Java escape codes.
I have access to Oracle and SQL*Developer so I decided to get the database to do the work. A nice thing about SQL*Developer is that it just works to copy in accented characters to the SQL window so that makes it easy. I got Oracle to do the work by using the Oracle REPLACE function which did what I wanted. Now replace() is handy because the function can be nested with itself to call it repeatedly using replace() itself as the input. This makes it really easy to add new characters and build it up as they appear in the translation content. So here's the example code.
select
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
'Complété avec succès',
'é', '\u00E9'),
'Ú', '\u00DA'),
'í', '\u00ED'),
'ä', '\u00E4'),
'ü', '\u00FC'),
'ß', '\u00DF'),
'á', '\u00E1'),
'¿', '\u00BF'),
'È', '\u00C8'),
'ì', '\u00EC'),
'ó', '\u00F3'),
'´', '\u00B4'),
'ú', '\u00FA'),
'ë', '\u00EB'),
'à', '\u00E0'),
'è', '\u00E8'),
'ç', '\u00E7'),
'ê', '\u00EA')
from dual;
the output for the above will be
Compl\u00E9t\u00E9 avec succ\u00E8s
In Eclipse there is a handy feature you can check by hovering the cursor over the \u escaped text in a .properties file and Eclipse will show it in its displayed form with the accented characters.
I don't doubt there's lots of ways to do this. Which makes it a bit of an interesting or fun problem in a way. This is what I did which worked well for me.
The developers tokenize the UI screens and put the English content into messages.properties. an external team delivers the translated tokens, which development then puts into the messages_X.properties to complete the process.
With the Western European languages there are sometimes non-ASCII characters with accents or whatnot from the translators. In the .properties files I wanted to convert these accented and non-ASCII characters to \u Java escape codes.
I have access to Oracle and SQL*Developer so I decided to get the database to do the work. A nice thing about SQL*Developer is that it just works to copy in accented characters to the SQL window so that makes it easy. I got Oracle to do the work by using the Oracle REPLACE function which did what I wanted. Now replace() is handy because the function can be nested with itself to call it repeatedly using replace() itself as the input. This makes it really easy to add new characters and build it up as they appear in the translation content. So here's the example code.
select
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
replace(
'Complété avec succès',
'é', '\u00E9'),
'Ú', '\u00DA'),
'í', '\u00ED'),
'ä', '\u00E4'),
'ü', '\u00FC'),
'ß', '\u00DF'),
'á', '\u00E1'),
'¿', '\u00BF'),
'È', '\u00C8'),
'ì', '\u00EC'),
'ó', '\u00F3'),
'´', '\u00B4'),
'ú', '\u00FA'),
'ë', '\u00EB'),
'à', '\u00E0'),
'è', '\u00E8'),
'ç', '\u00E7'),
'ê', '\u00EA')
from dual;
the output for the above will be
Compl\u00E9t\u00E9 avec succ\u00E8s
In Eclipse there is a handy feature you can check by hovering the cursor over the \u escaped text in a .properties file and Eclipse will show it in its displayed form with the accented characters.
I don't doubt there's lots of ways to do this. Which makes it a bit of an interesting or fun problem in a way. This is what I did which worked well for me.
Subscribe to:
Posts (Atom)