Technology from a Tech Manager's View - Measure Productivity

It is always an intriguing topic about software development productivity. There are some attempts to measure productivity. From those numbers, there are some conclusions and team chaos and management challenge are knocking at the door.


First of all, I do not think this productivity is measurable. If a computer program can understand how much effort to solve a problem, this program will be smart enough to solve the problem. Then we don’t need software developers at all.

The worst thing about this measurement is let team members know about it. The assumption is measurement will give insight into the problem and eventually leads to a solution. Not mention the trust between employee and management is broken, the assumption itself has a fatal error. You can measure stone's size and weight and those numbers won’t change. However, the subject of the measurement is human who will change the behavior if s/he knows someone is watching.

Naturally the subject (human) changes behavior to make the number better. Will this change really improve the productivity? Most likely not. The first thing human subject can do is to game the system. Will this effort result in high quality software? No. When you know you are not trusted, are you willing to contribute more?

Einstein's noble prize paper is only a few pages. Essentially the attempt to measure is put equivalence between software development activities and operational labor work.

Technology from a Tech Manager's view - Coding Standard

I have been in this industry for more than 10 years. Growing from a junior dev to a senior manager, I associated my name with many projects. I witnessed some interesting practices during the software development, especially in a team environment. This post is the first post I want to share my thoughts as a tech manager.

Coding standard or best practice? I have witnessed so many attempts to set up some coding standards in a team and failed. There are still coding standard proposed every day and I bet there are some emails flowing around  now. I can't say all of them, but most of them, will fail miserably. I have seen quant code, dev's code, system admin's code, etc. It seems that everyone has its own coding standard. Every industry has its own way to practice the software development. Is there a general coding standard, or should a coding standard exist at all? 

Now days, I feel those standard or effort to push such standard does not make much sense. Programming language is a way human tell a computer how s/he understand and solve the problem. It is like human language. Is there a standard way or "best practice" to say something? Do you have the "best" way to describe how solar system works for a 10-year-old boy? Is the "best way" still the best when facing a 20-year-old? 

For me, I think the best way to set up the "best practice" to understand your team. if my team has quant or physics background people. They want to use single-character variable name, it should be fine. Take a look at those mathematics paper they read every day, it is not difficult to understand why single-character variable name is the best choice for them. 

If I had a team whose members are all system admins, should I ask them to define interface or introduce complicated inheritance? Definitely not. Does this mean my project will fail? No. 

My job is to have my team to tell the computer how to solve a business problem. My team will use a programming language + framework to describe the solution. As a tech manager, my job is to choose the right technology for my team. That technology should be the most efficient and convenient way to 

• understand and communicate among team members
• communicate between a human and a computer

The diversity of technology is the outcome from innovative person and team to serve different people in different business environment. If you are pushing for innovation and still enforce a rigid coding standard, think twice.

Solve Automation & Biz Flow Project Resource Problem with PowerShell

When I take over the DevOps project to do the automation work. My project is not juts to streamline the software development process, it involves in large number of internal systems. For a company with many legacy systems and different business process. It is literally re-engineer the business flow.

My challenge is to have the people who know the business flow and the technology and make them work together. I do not want to hire BA because I have enough people who know business knowledge. The pressing task to have more person to code the logic. Thanks to my language background, the solution I found is to use different languages to solve the problem.

The first decision I made is to have no-GUI at all. The fancy GUI is nice to a new user; however, it will block the future automation for good. When you have a meeting with your financial planner, you will notice how many times s/he do copy/paste from one system to the other.

To fast code the solution, I need a scripting language or a language support scripting feature. That language should be good for folks with less coding experience. I do not need them to understand what is singleton pattern or difference between NTLM and Basic Authentication. I want my dev team to focus on the technical challenges and provide API's. Biz-background people can use those API's to streamline those processes in his/her area.

The initial setup is like the diagram following. Part1 is finished by biz people by invoke API's provided by dev's working on Part2.

I landed on the PowerShell language for Part1. PowerShell (PS) is designed for support/op folks. It has large number of samples. The most compelling reason for PS is that it can move the interface line from top to very bottom in the above diagram. PS can go deeper. Almost everything C#/F#/VB.net can do, PS can do. At the project initial stage, Part2 is much bigger than part1. I want a language has the potential to go deeper to the binary code in case my dev does not have the bandwidth to provide API. Other .Net languages can invoke PowerShell as well. As a result, the coding effort has little waste. A perfect eco-system where every bit of coding effort can be used and reused.

The current result is my biz people can code PowerShell and slowly push the "interface line" down to the ultimate binary format. The dev side does not have to deal with those "boring" business work. And the dev workload is getting less. By using PowerShell scripting language,

• Efficiency: one line PS code will do 10+ lines of .net language code. The overall progress will be faster when using a scripting language. 
• cost saving, I have the potential to expand my team to accommodate more people with various programming level
• Solid and quick solution: both parties can focus on the area in which s/he has deep expertise. The implementation speed is good.
• Flexible solution: since the interface line can move up and down based on the resource / expertise. 
• Vendor-independent: my solution is general enough so won't be locked in any vendor's customized solution. 

When the automation happens, one of the push back is the job lose. Having a person in the domain is the deciding factor for project success. The PowerShell provide a comfortable environment for biz people to start and grow, which makes my biz part team stable. 

To use a widely adopted language also stabilize the dev side. I witness many effort to have an in-house language which is only used in that team. Many vendor solution provides a programming interface which few people know how to use. The customized solution literally blocks the people from mainstream technology and few people wants their career to be in this situation. If you search for PowerShell, you can still find job openings requires that skill. This option really helps the adoption of the solution. With .net core moves to Linux platform, PowerShell 6 and all other .net languages will flood into Linux world. So the future is really bright. 

So far I am very happy about the result!

BTW: if you want to use F# to write PS module, here is the link.