My Job Is To Meet Expectations

This is a reply to the article Your Job Is Not to Write Code by +Laura Klein. 

It IS my job to write code. That code has to meet the expectations of the end users, the product manager (PM), the Quality Assurance Manager (QM), the support team, and myself.

The PM has to set the bar. Functionally and performance wise. If the PM leaves it up to me to decide what the code should run on, on what kind of hardware, that PM is not filling the role. The PMs are the ones that set the targets.

In a proper development team, it is NOT the developers job to test that the code runs on all variants of hardware. This is where you have testers, and a PM and a QA Manager (QM) that define the bar of what is acceptable function and performance in accordance with the specification you created.

The developer may be given his/her own test machine which can be used for “worst case” scenarios, but it is the test team that has to validate on a decent sample set of environments.

I might be a hired hand, and probably do not know all there is about the trade that the software is developed for, nor do I know the clients or how they actually use the software. Over time, I might learn this, but only as far as the PM lets me.

It is my job to think of the what-if’s. Actually, writing code is all about what-if’s. However, it is the specifications that decide the scope of the what if’s.
Should I recognize different number formats? Date formats? International characters? Right to left text? What should the default value be when a calculation fails due to a division by zero? What should the correct behavior be when a criteria is not met? All these things are about specifications defined by the PM according to the needs of the clients.

When I “check in code”, I should NEVER EVER check it into production. I should push it to a proper staging environment, and write roll out documentation, then the test team should roll it out on a test environment, validate that it works, refine documentation and then hand it to the support team for rollout to production.

If the PM did not ensure that there is proper QA, it is that PM that is responsible for the shitty code in production. If the product doesn't do what the customer expects, it’s the PM that did not write proper use cases and proper specifications and operational parameters, and it would be the PM that did not ensure that the QM had created the necessary test cases and functional specifications.

My skill is not customer management. My skill is not necessarily to know the business that the client is in. My skill is to transform various degrees of incomplete specifications into something that resembles what the customer wants, within reasonable time, and with a reasonably high quality.

The PMs are the ones that defines what the customer wants.
The QMs decide if what I wrote, meets that definition.
The support team will be the ones that verify that the definition actually was complete and correct.

Good software meets expectations. Good software is a process. Good process depends on team work. Team work depends on a certain degree of separations of roles. Roles are defined by responsibilities.

My role as a developer is to write code that meets expectations.

In some companies, these roles may boil down to just a few people — or even just a single individual. The roles are still there. The responsibilities are still there.

If the CEO doesn't understand or care about these roles and allot the necessary time and/or resource — that company will be fighting fires, playing blame games, and losing clients.

Sincerely,
Your Developer
Lars Fosdal

The Google+ Delphi Developers Community has reached 3300 members, as well as 800+ members in the Delphi iOS & Android Community. The Delphi Component Directory  also carries posts about component updates. FYI, there is a C++Builder Developers group as well, where Brett Wilton is primus motor

In case you have withdrawal symptoms from the EMBT official forums, you know where to find us ;)

Please note that the Delphi groups are strictly for development related discussions, and that if you have a need to vent about prices, EMBT, policies, or other non-technical issues, you should post in this group instead.

Google+ Delphi Developers Community: 2400 members and wishlist for 2014!

In January, the Google+ Delphi Developers Community will have it's one year anniversary. With 2400 members, as well as 300+ members in the Delphi iOS & Android Community and the Delphi Component Directory, I really appreciate and enjoy the posts and discussions about my favorite tool!  

As you know, in the Yule time it is not unusual to send off a wish list to Santa, so here are my wishes for Santa (+David Intersimone) and the Code Elfs at Embarcadero for 2014. 

Make 2014 a year for improving what exists!

It has been said before, but I cannot help but repeat my burning desire for having the list of "old sins" significantly shortened, instead of even more new features. Many posts during 2013 has been about performance issues or missing implementations, and to mention some: Generics weirdness, threading related issues, efficiency of generated code, lack of newer Windows APIs, lack of ready made wrappers for Android Java APIs,  IDE memory management and debugger/emulator stability, IDE features such as code insight and error insight which behave erratically, ...I'll stop myself here ;) 

Make 2014 a year for  engaging the communities!

We have a lot of awesome people making awesome fixes, improvements and workarounds for known Delphi issues.  I would love to see these people be given some love from EMBT and their excellent work adopted and integrated into Delphi.  We also have the open source efforts for creating regression tests for the Delphi libs, and it would be awesome if this effort would be adopted and supported by EMBT.  

To sum it up: 
2014: No new platforms and lots of fixes!

That was my wish list. 
What would be your Xmas wishlist for Embarcadero?