AI and Oracle

A long time ago in the 1990s I was starting out in software. Going to university Computer Science and alternating with co-op work terms.

I was talking to the father of a friend. He was high up in the Coast Guard. A good man. He knew about ships and navigation. He knew enough about computers to use them. 

He asked me if I could build systems in Oracle. Not knowing much I said I could work building applications with Oracle. I added might be more suited to working on the Oracle database itself. Like I said I didn't know much at the time, and didn't realize how little I knew. Every co-op student and entry level goes through this.

Then as now, of course there are a few hundreds of people working on Oracle, DB2, Sybase (now SQL Server). Working on the database itself. This is dwarfed by the many thousands of developers working building applications on these databases, and by many DBAs administering these estates.

So the Coast Guard man was right. He understood Oracle. Oracle is the business applications that run on Oracle, and the developers who know how to build and operate the business applications.

Years ago where I work now. We brought in this scaled agile SAFe consultant. We were in a big conference room at a local hotel for a few days. He described software development as unchanged since the 1950s. Chiselling out code line by line. I've been paid good money in software chiselling out source code line by line for over 25 years now.

So now there's this new, more recent thing around AI. It seems AI can be made to do more of the work, including writing the code. Like computers, AI is powerful. Computers are powerful but to be useful they need people, developers to write code for the applications that run on the computers.

AI and LLM are also powerful. Even in these early stages they have demonstrated some powerful capabilities, impressive possibilities. The AI requires humans to direct it, to provide inputs, tasks to perform with detailed instructions. The term prompt engineer has emerged as a new job category.

So with AI it may unfold similar to Oracle. There will be jobs at OpenAI, Google, Microsoft, Facebook etc. building and tuning the large language models, innovating in AI itself. Most of the jobs will be people who are able to work with AI, getting the AI to produce valuable business applications. 

AI may create a challenge of displacing some or perhaps most traditional coding positions. There may also be opportunity in AI around prompt engineering. This should be well suited to people capable of getting paid to write code.

The top of the heap pulls back

There have been some changes in the recruiting landscape. Back in 2021 I noticed a lot of reaching out on LinkedIn. Even recruiters from top of the heap FAANG were reaching out sending unsolicited messages.

That is no longer the case. At the peak I was being contacted by some recruiter around once a week on LinkedIn. In 2023 this slowed to around once a month.

The top firms went from hiring to shrinking. Microsoft, Facebook, Amazon, etc. all shed thousands of employees. An recruiter from Facebook who had contacted me updated her LinkedIn to no longer with Facebook, and the dreaded green Open for work badge. I deleted her from my contacts. 

A guy I know from wayback was at AWS. He seemed to survive the first Amazon round. At an end of year lunch another individual from back then mentioned he's no longer at AWS. I checked LinkedIn and it seems he got caught in the second big Amazon layoff wave. As of mid 2023 his time at AWS seemed to abruptly end.

And so it goes. I'm sure the top firms are still hiring exceptionals for key roles. You can get on there but it's hard now, like historically it was hard to get on at Google.The indiscriminate growth and hiring, and them reaching out first era has ended for now.

There was a lot of swirl for those like me who stayed where they were during the great resignation of 2020-2022. We lost people to Microsoft and AWS. It was disruptive. I do hope for a balanced market where there are good jobs available to those who are seeking new work, and quality candidates available for employers who want to hire.

The New IBM Fungibles

IBM has announced they are going to replace 7,800 jobs with AI. That is quite a few people. IBM is vast though at around 260,000 employees. 

Ah the IBM fungibles. First they were laid off and replaced with other fungibles. Now they are laid off to be replaced by AI and bots. Still there, and will be in great numbers. There are many thousands of them remaining. Still going to work at IBM, still grinding, still getting paid. At IBM and through tech.

Life on the 80 side of the 80/20 rule. Under the Pareto principle, the top 20% of contributors generate 80% of the end user value. The fungibles are the other 80% of contributors. Still useful, able to generate billable hours, can complete many tasks and make real contributions to delivery, in great numbers. Always under that bit of pressure though. The outsourcing craze of the early 2000s, seen as interchangeable and replaceable with each other, now the AI craze for this decade.

The top of the heap reaches out

If you made a list of the most prestigious software companies, the best, most desirable places to be. At this time in July 2021 the top of the software heap might look like

Google
Facebook
Microsoft
Apple
Amazon
Netflix

and right up there, not far behind I might include

Zoom
Uber
Twitter

now your list might be a bit different. maybe add or remove a couple here and there. but in general, these are considered the top, the biggest and most successful companies, the most sought after jobs. some use FAANG which is basically the same list.

what's interesting is that in the last few months two of these companies have reached out to me unsolicited from LinkedIn. I've been contacted by Amazon and Facebook. asking me if I might be interested in applying for something. I told them polite thanks, I'm not looking to make a change at this time.

I've been on LinkedIn for a long time but this had never happened before. So it's a bit unusual for me to be hearing from them. I haven't really made any meaningful changes to my LinkedIn profile that might be drawing extra interest from the search queries the elite companies presumably use to assemble lists of people to reach out to. But somehow I've now appeared on these queries twice in the last few months.

I'd think historically they have had plenty of high quality applicants to choose from. I'm basically a regular software developer in Nova Scotia with north of 25 years experience. It's a bit flattering to hear from them. Still I understand how rigorous their recruiting process is. I don't have any more illusions now than in the past about being able to successfully navigate that notorious process. It's a long way from sending an unsolicited email on LinkedIn to extending an actual job offer.

I got thinking about why they now seem to be reaching out further to find candidates. I suspect part of it is just how successful these companies have been, and how much they have grown. They may have outgrown the ability of traditional recruiting sources such as Stanford, CMU, MIT, Concordia, Harvard, other companies in Silicon Valley, to generate employees. So they have to be more creative to search further afield to find quality new employees to hire. Then there's Price's Law. It takes 1 million programmers to generate 1,000 exceptionals, the people Google wants. It takes 4 million developers to generate 2,000 exceptionals.

The 1 in 1,000 exceptionalism. These people are great of course and highly sought after, but are very rare. There could only be a few thousand in all of North America. Many are already onboard at Google and Facebook anyway. Of the rest, many have great situations in academia or the companies where they are at. They can't be lured to Silicon Valley or Seattle. I'm guessing the target for elite tech hiring is more around the Pareto principle. Under Pareto, 20% of developers generate 80% of the software progress. If we accept my speculation that the 20% Pareto group is a fractal, it's also Pareto distributed. Then 4% of developers create 64% of value in software. It's these 4%, the 1 in 25, who big tech is reaching out further to identify and recruit.

One factor which may be influencing big tech to reach further out is the increase in work from home. If there is some guy in Cape Breton who is outstanding, and would do fine in California. He is happy living in Cape Breton and not interested in moving. With work from home, big tech might be able to still recruit him, which would not have been possible in the past.

It's a big challenge for the elite firms. How to continue to grow and increase the head count, while maintaining the extremely high recruiting and hiring standards that have made them so successful. Reaching out further, to less familiar candidate pools, may increase this challenge further. Though there are outstanding people "out there" to be found. I've had the pleasure to work with a few over the years.

25 years in software development

A few months ago, in 2020, I realized something. I started my first job in software in 1995. I've now been a computer programmer for 25 years.

My first job was with PRIOR Data Sciences in January 1995. I was a co-op student from the Technical University of Nova Scotia (TUNS) on a four-month term with PRIOR in the Halifax office. The pay was based on annualized $25,000 a year. it was the highest pay I'd received anywhere. yay good start. Working in software has always paid well with good benefits.

The project, PLAN CSCI at the time, was part of the Iris radio program for the Canadian Army. PRIOR had this small piece of a big program, which was a big multimillion contract to PRIOR, and created a job for me. We were actually a sub-subcontractor, working for EDS in Hook, England, who were working for CDC in Calgary.

It was a good work term. I worked on Oracle Forms and some Ada. I wrote the original forms manager module which continued into the final completed system. I learned a lot.

I guess PRIOR was happy enough with my work. They invited me back for two more work terms, then when I finished at TUNS I joined as full time in January 1997. PRIOR was a fine company, a good place to work, with talented individuals throughout. In 2000, xwave bought PRIOR for $15 million as part of an acquisition spree.

I joined xwave with the acquisition. They were okay, benefits weren't as good but they treated me well and I can't say anything bad. xwave had the bad luck to hit the tech crash of the early 2000s. It was a different feel with xwave. For myself I made my first job change, joining Core Networks in July 2001. The pay was 8% higher.

business cards from over the years. developers were last issued business cards about 15 years ago

Back then, working in software development was in three broad areas
product based companies
consulting and systems integration
corporate and government IT departments

I've worked in all of these environments at different times over the years. My IT department time with the Department of Fisheries and Oceans (DFO) around Y2K for about two years was as a contractor from PRIOR/xwave. Showing that there is some overlap between them.

This is still pretty much the same today a generation later, the three areas where developers work. Some of the details are a bit different. Products then was shrink wrapped consumer, and enterprise software discs for corporate servers. Today it is websites, web-based applications, and app store apps.

Consulting has seen the rise of outsourcing and offshoring.

In enterprise IT, more servers and corporate applications have moved to the cloud and AWS.

I started as a software developer in 1995. In 2020 I am still a computer programmer. That's not entirely unusual. it's a good job, the pay and benefits are good. Indoor cubicle work (from home) with free coffee. Like everyone in tech, a good number of evenings and weekends, with a few death marches and all-nighters over the years. 

Some who started as programmers have moved on to other positions. The main areas people branch out to from development are management and architecture. as for everyone, there were opportunities where I could have moved things in those directions. meh I've always been happy enough to be a developer.

I think about it like an electrician. If someone is an electrician for 25 years that's considered good, an accomplishment, a winning career. Nobody would question why an electrician didn't seek to become some kind of manager or start his own company or whatever. He became an electrician to work as an electrician. He was good enough at it to stay employed and had a long prosperous run doing it. A success.

When I joined PRIOR full time PLAN CSCI had expanded into the Communications Management System (CMS) Segment, which included PLAN. My contribution was the Offline Storage Media (OLSM) Computer Software Unit (CSU). OLSM was a good piece, well received by the Army in testing I was told. I'm pleased to have written it and be associated with it. OLSM was written in the Ada programming language, now known as Ada 83. I was on the Ada team for CMS. That was a very strong team, certainly among the best teams I've been on over the years.

Ada is a good programming language. It can be enjoyable to work with on a good software system. At the time I thought I wouldn't mind doing Ada maintenance on a large, well-designed system for a number of years as the rest of my career. That statement remains true today.

At this point it's likely I'm closer to the end of my career than to the beginning. 25 years ago I was close to the start with years ahead as it has turned out. There's no guarantee of course I have 25 years left to live, and retirement is a real thing for some people. So who knows? Unexpected events, major upheavals for better or for worse, periods of prosperity and struggle, can and do happen. The world of professional software development has changed in the last quarter century, and I expect change to just continue. For myself I'm definitely in the "danger zone" of the middle-aged tech worker. As far back as the 1980s the unemployed 40 and 50 something technical worker was a thing, an issue in tech. I used to see articles about it in high school. We don't hear about that as much today, but I'm not sure I'd want to be out of work and seeking to get back into software.

I've worked for 7 different companies. So about 3.5 years average. That's not bad in software. Some of the changes such as PRIOR to xwave were due to my company being acquired. I switched jobs on my own three times. Luckily I was only laid off and out of work once in all these years so far. In 2014 as RIM was going from 19,000 to 2,000 employees I got severenced when the BlackBerry ID (BBID) server team in Halifax was laid off. A couple of months after RIM I caught on with CGI.

lapel pins from along the way. TUNS, PRIOR, and Core Networks no longer exist

Final thoughts. I've been on a number of teams with a number of companies over the years. There have been many theories and methodologies including: personal offices with doors that close, pair programming two people at one keyboard, shoulder to shoulder and across from each other at long desks, work from home, Booch notation, Unified Modelling Language (UML), stick figure men, user stories, scenarios, design patterns, Microsoft Word design documents, MS Project, Jira, waterfall, agile, scrum, SAFe, kanban, Toyota, Spotify, probably other stuff and fads I've forgotten.

What makes a successful software team? From the above, it has been thought about and many ideas have been tried. In my early years as a developer I came up with a theory. I've stuck with it ever since. My theory is there are two factors that define a successful software team

• outstanding individual talent. exceptionals and solid individual contributors
• stability and continuity

With those two things the team will be successful whatever current design methodology or way to organize people and work is used. Without these two things, especially talented personnel, no amount of software design or organizational fads will overcome it; the team will struggle.

That's it. twenty-five years in the books. it was a good choice for me getting into this business. hopefully I have at least a few good years left.

Is Code the Future of Test

Where I work there is increasing focus on test automation. Recent hiring around the quality assurance area has focused on those who can create and maintain automated tests.

Test automation is about source code. So at least some programming skill and experience is now basically a requirement to be hired into QA. Of course there is still a requirement to be able to do more classic manual testing. That is, going to the website, desktop, or mobile app, executing various flows in person, observing and verifying the result is correct and the user experience is smooth. The way forward seems to be dual-hat in QA. Comfortable both in manual testing and test automation.

This tends to blur a distinction between manual and automated testing. It's all testing. The trend in my observation seems toward eliminate the separate test automation teams, the 3 teams doctrine (dev team, manual test team, test automation team).

It also tends to blur a distinction between developer and tester. Going forward it may become that QA/test automation is generally the entry level position out of tech school. From there, the individual will have the opportunity to demonstrate an ability to write clean, maintainable code that works as part of test automation. That person could if interested be offered an opportunity to switch from QA to development.

So I'd see a scenario something like this where dual-hat QA is capable both in manual testing and test automation. While manually testing a screen on the website, a tester notices a problem. The tester files a bug report in the usual way, reporting steps to reproduce, expected result, actual result, screen shots, logs, etc. While the bug goes into the development team, the tester then creates an automated test to demonstrate the defect on the website. The automated test is reviewed and checked into the repo. A couple days later the development team marks the bug as fixed and ready to verify.

The tester goes back to the screen on the website with the latest build. The defect is observed to now be fixed. The automated test case runs automatically. The automated test switches from red to green, confirming that the issue is now fixed. The defect is closed. The automated test remains in the repo and runs in the overnight regression test run to help ensure the defect does not accidentally reappear in the website.

What of the classic manual tester?
I think the traditional non-coding manual testers will be around for some time. There's plenty of work in that area. They are not yet an endangered species. Not every company has fully embraced dual-hat QA. Anyone who has a job manual testing is probably pretty safe.

Perhaps it will start to be felt in mobility if you lose your job or seek to switch jobs. For example where I work it seems all new QA hiring now requires coding and test automation ability. So by that definition any manual testers here might have a harder time getting hired by today's standards, even though they are good at their jobs and make important contributions to successful product releases. So I suspect QA hiring across tech will increasingly require the ability to fire up Eclipse, Visual Studio, whatever IDE, understand code, and write code.

To the existing manual tester there are some paths forward. Be really good at manual testing. Consider reinvent as a business analyst, product manager, project manager, or into management. Also if possible fire up the tools and learn/relearn to code and embrace test automation.

What is the future of Development?
I think that will also evolve. It's worth its own post. I should think about it some more and may come up with something.

2 Years of C# and .net

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.

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.

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.

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.

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.

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.

good and bad developers

This week a guy announced he is resigning. He gave more than two weeks notice which was classy of him. He was a good guy, he made some useful contributions.

It got me thinking a bit about software development teams. At the site where I work there are several hundred developers across many teams for different clients. At a very small number of places like Microsoft, Google, Facebook, there are no weak developers. Those firms have the advantage of a constant stream of outstanding applicants so they have the luxury of having pretty much everyone being very high performing.

In general at places where I've worked over the years, there was more of a mix. Some really outstanding developers, some solid pretty good developers, some mediocre developers, and some low performers.

Now when someone quits, it's almost always someone from one of the first two groups. They tend to have better prospects and people who worked with them in the past will keep in touch more and be agreeable to them working with them again at some new firm. The lesser developers tend to have much less mobility so they tend to rarely leave voluntarily.

Now with recruiting replacements it tends to follow the breakdown of the existing developer population. So sometimes the replacements can be as good or better than the people who quit, and sometimes you will be unlucky and bring in someone from groups 3-4. So over time on its own then what could happen is that inevitably the ratio of good and very good developers to mediocre and bad developers becomes less. Entirely due to the differing rates of attrition of good and bad developers, and natural variance in recruiting replacements.

This will cause a bad situation over time as developer skill is by far the crucial factor in the success of a software team. While most teams can and have to carry some mediocre and weak performers, there needs to be a healthy percentage of good developers to be long term sustainable and successful.

So I realized something. When a good developer quits, then the correct move for the employer is to also fire a weak developer at the same time. So instead of having to bring in one new person they recruit two. This is crucial to keep the team balanced and the proper ratio of strong developer to less strong. So when bringing in two new people ideally they will both be good. But if variance hits and only one is really strong then the overall team is still ok and the team remains well balanced.

back at work

There's some news on the job front. I have found work. After I was laid off I had an informal list of people to contact who I'd worked with in the past. It was to get references and see if they knew about any leads. I also updated my resume and posted on Monster and Career Beacon.

There were a couple of leads and I put my name in at a few places. I got an interview and an offer followed. It looked okay so I accepted the offer and returned to work in July. I was out of work for a bit more than a month. So that wasn't too bad. Good to have paycheques coming in again that's for sure.

I caught on with an IT consulting firm in the Halifax office. I've been in consulting in the past from 1997-2001 back with PRIOR Data Sciences and xwave. It's a bit different than doing commercial product development from the years at Core Networks, SupportSoft and RIM. Writing code that we don't own. It's nice to be billable again and generating revenue, instead of being a cost. It's a Java and Oracle project I'm starting out on so that part is still pretty familiar.

I miss work from home at times. But the commute is pretty favourable to where I live so it hasn't been too hard an adjustment. So a new chapter begins.

laid off

well it finally happened. I was laid off from a high tech job. it was back in June. I was working at home. a little after 10 AM the phone rings. it was the director. he was mumbling and it was hard to hear. he said something like there's bad news there's been a reorg and I've been downsized. my work duties end as of the end of this phone call. There was also an HR person on the line and he handed it over to her. he seemed anxious to get off the call so I didn't keep him. It was over in about 30 seconds.

The HR stayed on about 30 minutes going over the many details of severance. There were some complications because of work from home. Usually in office the person is just run out the door and your cubicle is left behind for IT or whoever to scavenge or clean up. someone might meet you after with a banker's box of your personal stuff like headphones or whatever.

so that's that. I survived a great many downsizings over the years. statistically I was bound to get caught up in one eventually. meh RIM went from 19,000 to 5,000 employees in the last 3 years so for everyone, any day you go to work at RIM could be your last. well I got ahead financially at RIM and iPhone had been released when I joined in 2008 so I knew going in. I did get my severance which will come in handy.

The Phoenix Project by Gene Kim, George Spafford, Kevin Behr

I recently read  The Phoenix Project: A Novel About It, Devops, And Helping Your Business Win. It's a fable about Bill, the director of midrange computing at a fictional large auto parts manufacturer called Parts Unlimited. Bill has set up a comfortable life in middle management in the orderly world of AS-400s.

One morning Bill is called to the CEO's office. He's informed that the CIO and VP of IT operations have been terminated and Bill is now the VP. So Bill is reluctantly thrust into being a freshly minted VP in a role he did not seek. Bill's early tenure is marred by numerous IT disasters such as a failed launch of a major product called Phoenix, a failure to make payroll due to an IT issue, and a failure in the retail point of sales system. Bill has to work extremely long hours dealing with these crises and it begins to take a toll on his family life. To make things even worse the CEO presents Bill with an ultimatum. Fix IT in 90 days or the IT department will be outsourced.

Early on Bill is introduced to a mysterious guru character named Eric. Eric teaches Bill about how IT can be approached like manufacturing. Eric takes Bill on tours of a large manufacturing plant. They discuss inventory and work in progress, the evil of inventory in manufacturing, and how to apply this to IT.

Eric introduces the modern concept of DevOps. In devops development and operations are combined. So the idea is to reduce this "over the wall", "works on my PC", "all hands on deck deployment", "developer role / IT role", "separate performance testing" dysfunctions and inefficiencies. Replacing with one piece flow and continuous deployment.

The book was ok. It was a compelling read for the first 100 pages or so. It dragged a bit in the last 50 pages. From the developer side I could relate to a lot of it. Parts of the book, especially toward the end, came across as a bit autobiographical and self-congratulatory.

Still it was worth reading. The director at the time ordered everyone to read it and I've finally got around to it. I'm not sure if it was supposed to make us think, or it was "this is what we're doing now." I got it from the local library, as the manager at the time refused to allocate budget for some local copies. I guess that shows how important it was - brand new hardcover copy can be had for $20 each. meh w/e.

It was good for me to see more the IT operations side and what happens to both prepare for, and to support deploying the code that the developers release. I've written about one piece flow on this site mostly as it relates to the software developer experience - since that's been my area all these years. It was good for me to get some more insight into the IT side. I was pleased to see the same principles of value stream apply on the operations side too. So it can be integrated with development if the effort is put in to set it up.

the trouble with JSF

At work the last year has been back to the future in development. After a reorg in 2012 the DI team morphed into a disastrous and miserable time with some larger devops team who didn't want us, and we didn't want to be with them. I returned to Java server development in January of this year. In March of this year there was another reorg and devops vanished and the Halifax branch was swept out the door. So I narrowly avoided that fate. devops is not missed.

It's been a good year back in the saddle of development. It's where I belong and I can still produce quality design and code. I've always liked Java and I had some good Java years back at SupportSoft. This past year was a good year.

At this point my plan is pretty much to try stick with Java as the go forward plan. Even if the creation of new Java code suddenly and unexpectedly ceased the existing Java base is massive and there should be enough legacy out there to allow me to run out the remaining years of my development career. We'll see. There's still quite a few years to go on that!

So my dev team has a .java backend with a front end website. Most of the action happens in the backend but the website isn't exactly small. The website has been around for several years with the typical nooks and crannies and special features. It is built using Seam and JSF. I was at the website a bit but mostly I worked in the .java part. It's not an area of interest to me and there were other developers who were more interested in UI.

So after observing and being around the JSF for a year, writing some JSF code and being on code reviews, I can finally articulate some things that had been in the back of my mind about Java web.

The thing about JSF is this: where is the Java? You try to do anything and it's all .xml, .xhtml, .js. .css. etc. You virtually never touch a .java file. Why would Sun/Oracle spend all these years promoting a non-Java technology stack within the Java standards? It doesn't make any sense.

There are so many things wrong with this strategy. Java developers don't really mind doing UI. What they mind is being required to leave behind their years of skill and experience in Java to work with this completely different stack(s) that has nothing to do with Java. So we just don't really want to leave Java and why would we. And it is so painful having to learn all these multiple and large foreign syntaxes and terminologies just to get a basic screen to come up. And don't even start on "this code is correct but it doesn't work on version X of browser Y running on desktop OS or mobile phone Z"

So what happens is the Java development team becomes split. Those who do UI and those who don't. That's what happened at SupportSoft. This should be so avoidable. The strength of Java is that it's generally easy for a Java developer to move into a new area such as database, crypto, XML processing, business logic, etc. With JSF because it's not really Java there's this huge barrier with large up front learning curve and no easy transition.


For a long time this JSP/JSF situation was something that developers were just expected to shrug and passively accept. Kind of like the way it was with EJB back in J2EE. After all it's the "standard" way so too bad. Luckily some others realized before I did that the JSF approach is fundamentally flawed and going in a new direction away from a broken standard is better.

You can see some of that on the GWT overview page. This is basically the first words out of their mouth

... goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript

It's like, wow, the anti JSF. productive development. not having to be expert in browser quirks and JS. you also don't have to leave Java. you know, Java, that thing you invested years of your career mastering and promoting. It's so bizarre that Oracle/Google lawsuit over Java. Google has done more than pretty much anyone to preserve, promote and advance Java.

thoughts on the Obamacare rollout

Along with the "tech surge" I heard Google and Oracle have volunteered personnel to help with the healthcare.gov site. hmmm this seems to violate Brooks's law which states that "adding manpower to a late software project makes it later." So now time will be lost answering questions and bringing all these new people up to speed.

I read Obamacare came in at 500 million lines. what is the system doing that requires so much code? By comparison Windows8 came in around 80 million lines. So this system is really six times bigger and more complex?

I'd like to see the looks on the Google and Oracle developers faces when they see the Obamacare source code for the first time. Welcome to corporate/government IT!

I'm confident CGI already has a very deep understanding of agile. The probability that the issues can be traced to a lack of agile, or misimplementation of agile, is basically about zero.

A lot of the problem can be traced to the immovable deadline. If X million must be signed up by end of March 2014, then the site must go live no later than end of September 2013. So they went live because they had to and they obviously weren't ready or particularly close to ready. So it's just another big government IT project, late and over budget. But with the hard launch date there's nowhere to hide and no way to slip on the delivery.

It's easy to vilify CGI. To be fair, the go live deadline wasn't their estimate. It was Congress who dictated when the law was enacted that a 500 million line system would be built and ready in Z months - with apparently no consultation with the people who would build this system if this was realistic. CGI tried but it may have been an impossible mission.

sent home, to work

There was a big local downsizing last week. The entire office is being closed, the remaining four occupied floors from an office built in 2008. ah the brand new building, the high tech kiss of death. I guess it was to be our contribution to an overall 40% global RIF.

A fraction of the locals, around 10%, were told they will be working from home in January after the office closes. I was among that group. Statistically at least it was a bit of a surprise. Although it's more like still in the running for January rather than a lock. There's new management scheduled to come in early November so who knows what decisions they will make. At this point the plan is to start work from home in January.

In some ways I'm looking forward to it. I won't miss the commute in winter. To think about it, how much time and money has been wasted on commuting over the years. I know some people who work from home and they speak well of it. In some ways work from home has executive perks including

• work location chosen to optimize your commute
• private office
• personal printer
• private bathroom
• own coffee machine
• comfortable high backed manager's chair (go for it)

The company has been pretty good about it helping to get the space set up. That will still take some thinking where to fit the new desk at my place. Overall I see it as a positive change. Some things will be different and a bit harder but overall to me it seems like it's the same work so why not do it from home.

a modern software team test

I remember the heyday of Joel on Software back in the early 2000s. It was a great site with excellent articles coming out every month. The forums were good too.

One of the major posts with remarkable sticking power was the Joel Test. At the time back in 2000 it was like wow a way to quantify how good your team was. And Microsoft, the top of the heap, does all 12. Joel was probably right that most teams were about a 2 or 3 at that time.

Today I'd say the industry has matured and with tools like Jenkins and Bugzilla and git available for free. Most teams I've been on over the years I'd say are around 7-10 on this scale. and scores have generally improved over the years. culturally I think a lot of that stuff is now standard and most teams, even mediocre teams, would just put a lot of that stuff in on their own now without having to be told to or getting resistance from management. as noted above since the stack is generally free it helps a lot that it only takes one good developer who cares about it go establish a pretty good stack off some spare Linux VM somewhere at no cost to the firm.

So using the Joel test as a starting point, what are some guidelines to today's software development teams. well here goes

1. do you use visual tools?
2. do you have automated testing?
3. do you use static source code analysis?
4. is all code reviewed?
5. do you build on every check in?
6. do you level the workflow?
7. do you use one piece flow?

1. do you use visual tools?
For your current project, how much stuff is in development? how much in code review? how much with the test team? how many requirements and defects are in the project scope but not yet assigned to a developer? at this moment how many issues on average are assigned to each developer?

With visual tools the process runs more smoothly as problems such as open code reviews piling up, or a negative find vs. fix ratio on defects are obvious and public. this allows issues to be identified and addressed much earlier, before it is a crisis.

2. do you have automated testing?
Since we work with computers let's get the computers to do the testing. there are some things computers are good at and software testing is one of them.

with powerful modern tools like powermock and mockito many of the historic barriers that made automated testing difficult or painful are no more. in general developers will write code. with automated testing we get development on board to write self-testing code

3. do you use static source code analysis?
Tools like Coverity and Klocwork are awesome. they find the really hard stuff, like did you know this API can return null on some obscure but possible scenarios. what happens in our code then? something the programmer overlooked but the static analysis found.

as well they find the "easy" stuff - uh this will NPE, oops. quick fix yay

4. is all code reviewed?
code review done properly is an effective and cost efficient way to find and fix runtime software errors at the early stage, when it is still very inexpensive to fix them.

5. do you build on every check in?
if someone checked in code that doesn't compile for whatever reason (such as forgetting to add a new file to the repo), then it should be made known so it can be fixed ASAP.

this checking is also part of the automated testing. after compiling the code it makes sense for the computer to also run the automated tests since it's free at that point. again if a developer broke or possibly broke something then everyone should know about it right away so it can be fixed right away

back at a previous company there was an informal rule "never sync before 10 AM" that was because to sync is to pick up whatever stuff that didn't compile and didn't work had been checked in since yesterday. by waiting until 10 you could be sure that the offender was in and after spending time manually investigating the problem you could ask him to look at it and fix. so in the old days when someone checked in bad code it typically wasn't noticed or fixed until the next day.

6. do you level the workflow?
a reason to use visual tools is to identify lumps or bottlenecks in the workflow. if code review is being neglected and backed up then announce "halt production of new code until the reviews are cleaned up". so many years I've heard people throw the term "waterfall" around like some kind of stick to hit people with. but the team has to be willing to do something to combat waterfall, which is something of a natural entropy state. using techniques like Kanban and lean to level out the amount of outstanding work at each station in the software development process

7. do you use one piece flow?
Queuing is toxic to software development. queues destroy value stream productivity. if you look at the lifecycle of some feature or defect reported, on many teams you will find that the work spent the vast majority of its time idle, sitting in some queue making zero progress while waiting for a tiny amount of attention from someone before going into the next queue and being idled again

some defect is reported. it sits until the 10 AM triage meeting the next day. assigned to some developer who already has multiple assigned issues. it sits idle for a few days until the developer gets to it. developer codes and tests a fix in a couple of hours. developer creates a code review. it waits for the reviewers to get to it, more than a day passes to do the review which was an hour of actual work. developer checks in. the official build isn't until next week so the work is stalled, done but not delivered to the test team. a week later there's the build. the item is one of a large batch of items delivered in the build. the test team will get to it when they get to it perhaps a few days later after running through the full regression first. it takes half an hour for the tester to retest and confirm the fix

now with one piece flow these disconnects, queues, asynchronous handoffs and large batches of work are sharply reduced or eliminated. once work on some item begins it proceeds expeditiously with little or no delays between each station.