Outcry against Memo for new team members

Technical project management is an act of balancing. There are many interests. Some interests are inherently increasing product quality: someone may want to spend more development time for unit testing and documentation (to improve long-term maintainability), others want to spend more development time for small UI details striving for amazing user experience, yet another person might demand more time spent on manual testing, increasing testability and establishing clear operating procedures. There are also other interests that are often perfectly valid, but objectively they work against product quality, for example trying to spend as little time and budget as possible, trying to have so many features “done” as possible before an important deadline, or changing project team on-the-fly to balance company-wide targets.

Balancing these factors is not a simple task. And this was an example of a perfect team and perfect project! Sometimes things are less than optimal so that you might have additional out-of-scope factors, for example power struggles, striving for promotion at any price, or just persons enjoying their off-work life as much as possible and contributing only so much to avoid being fired.

Given that this balancing is a very non-trivial task, it is more art and intuition than logic and science. This opens a possibility for disagreement.

Once, I was technically managing one big project. I knew we were understaffed, and asked for more staff for very specific areas. I knew I wouldn’t get what I wanted. My guess was that I’ll get another person, a colleague of mine I had chance to work with in one of the previous projects. I didn’t like his approach of how to balance projects, even to the point of asking myself whether he can balance projects well. He was equally opinionated about my skills.

If he was to be added to my team, I saw a high possibility of disagreements about what development activities we’re going to spend our time on. I knew that this is an inter-personal problem and as such it must be handled in a personal discussion(s). But first, I’m not that good in soft skills. Second, it was a hot phase of the project and I was very busy with other, equally important things. So I’ve slacked and written down a “memo for new team members”. I was hoping to use my authority as software architect and the oldest technical member of the team to force my colleague to comply with my principles.

I was on the verge of defining a software development process for the only reason of avoiding a personal discussion with a team member.

This is embarrassing. Fortunately to me, this colleague was never added to my team, so I’ve never used this memo against him. And several months later some other unrelated issues have forced me to part ways with the project team and thus to avoid solving this problem altogether.

When I’m reading the memo today, I feel it is still useful though. First, it reflects pretty well my philosophy about how to create the very first iteration of risky innovative big software systems. Second, its language reflects how frustrated and helpless I was at that time, and it is so cute. Therefore I want to share it with you. Here it is.

You are going to be assigned to work with the %customer_name team. Please take a minute to read this memo.

Everybody in the team is a highly competent professional; therefore we generally avoid establishing any fixed rules that may never be broken. Nevertheless, we must align our initial assumptions to ensure the best possible software quality and minimize all kinds of risks.

If you want to enter the team you have to agree with the following:

I. You will not assume that you have the exclusive ownership over the source code of “your” subsystem.

Consequences:

a) You will use any tools or extensions not included in the standard developer PC image, only if their usage it absolutely necessary to accomplish the task.  Reason: if another developer will have to develop the subsystem, it might be too expensive or, in case of a very high time pressure, simply impossible to install those tools to be able to work on the subsystem.

b) And vice versa, you will not threat other subsystems as external entities or black boxes. Instead, you will actively read and understand their source code to understand their real behavior. Reason: if another subsystem doesn’t work as specified in the interface documentation, you are the one who has the best chance to understand what’s happening, because you might be the only person in the team working in this area, keeping all the factors in the short-term memory and having a reproducible case.

c) It also means you’re responsible for fixing bugs in those external subsystems (if you’ll happen to find one) or change their behavior if needed for your subsystem. Speak with the primary developer of the subsystem first, though. Reason: often it is easier to fix software directly instead of communicating the problem and then waiting for its solution.

d) The fact you’re primarily developing one particular subsystem doesn’t mean you will never develop other subsystems. You should know the “bigger picture”. Reason: you should be able to replace other team members in case of emergency.

 

II. You will not assume that you have control over concrete deployment and usage scenarios on any server except of your own development PC.

Consequences:

a) You will never ever include any production configuration files into the source control along with your source code. If your system will have a test server and you opt to include test server configuration into the source control, you will explicitly threat them as template / reference / sample configs and will not create any release scripts automatically overwriting the actual test server configuration. The re-configuration of the test server and all production systems will be performed directly on the systems. Version control of configurations and backup responsibility lies on persons performing re-configuration, and on system administrators. Reason: the software system will be operated by %customer_name. By reflecting that in our processes we make our environment more realistic. Besides, other persons will be able to re-configure the test server without having to get the source code of your subsystem.

b) You will split the system into separate applications. When feasible, one must be able to operate each app manually. In case when output of app A will be directed to the input of app B, the data exchange format must be kept as simple as possible, and it must facilitate manual creation (i.e. creating the input of app B without using app A should be as easy as possible and not limited in any way). Reason: in case of emergency or extreme time pressures, we want to be able to reconfigure planned data flow and hack some of its stages manually.

c) You will not validate any input upfront, except otherwise is explicitly specified in the requirements. Instead, you will provide meaningful exceptions in case the input is not correct. For example, if your input will happen to be a string, and some later processing stages of the app will have to threat this string as integer, you will keep the string being string up until the place where you need an integer, then attempt to convert the string to integer and, in case of conversion failure, you will throw an exception with a helpful message. In case your subsystem will be configured to avoid the step requiring converting the string to the integer, this string input must not be validated, unless explicitly stated by requirements.  Reason: your software must be usable even in the situations you cannot envisage right now. String in a format you consider invalid today, later on during the operation stage, or in case of emergency, might be reconsidered to be a valid value, depending on which processing stages of your app will be turned on or off in the concrete usage scenario.

d) In case your software will store data persistently, you will keep the data format simple so that it will be possible to change the persisted data manually. Reason: simplifies debugging and also fixing the system in case of emergency. For example, all things being equal, you should prefer to use MS SQL field type “Identity” over Guids for the ID field, because it is more time consuming to generate the latter when inserting a new row manually.

 

III. You will not assume that the subsystem is a long-living project.

Consequences:

a) You are allowed to write unit tests, but you will not try to cover most of functionality with unit tests, and you will not write a documentation about how the system works (except when explicitly required by the customer). Reason: In case of short-living projects, there is a better strategy to keep the subsystem maintainable: make it readable by keeping its parts extremely simple, and avoiding unnecessary classes, methods and lines of code.

b) You will avoid using frameworks and software development patterns (for example IoC, MVVM, etc) except when they really needed (i.e. would greatly reduce development time or increase security). Reason: each used framework and pattern might require additional time of other developers to understand it. The benefits of frameworks and patterns can be only achieved if the same team is working on the same subsystems for months and years, so that initial time investment in understanding the framework will be amortized over the long time. This is not our case.

%customer_name team wishes you (and all of us) a pleasant journey. Welcome aboard!

This Week in Twitter

  • Something like this. http://t.co/V8XILETS #
  • @bobuk ??? ???? ????, ?? ?????????? ??? ?????????? http://t.co/TophcizY #
  • @bobuk ???, ?.?. ?? ?? ???????? ? ?????????? ????????? ???? mozilla foundation? ??? ??????? ? ???? ????????????? ??????????? #
  • Gaokao. A week later, China is still resonating. RT @isaac: Gaokao Madness http://t.co/2L9tPoAa via @cdt #
  • Baby sunflower http://t.co/MtjXK17l #
  • An elaborate analysis of LinkedIn story, via addmeto.cc https://t.co/BtPyy52H #
  • I feel ashamed of the almost non-existently small emotional impact a typical (web)app UI has comparing to this video. http://t.co/42ExxwNP #
  • Anti-utopia authors didn't have enough fantasy to predict it RT @SAI 500 Years Of Angry Birds Are Played Everyday http://t.co/FctZEMBv #
  • Agree, putting Windows8 RT on phones would be the only natural way. The other question is if it is technically possible. #

Powered by Twitter Tools

iScreen or not? That’s the question

Hehe, the last chance to try to predict anything before it will be made official on WWDC…

In my previous post on the iScreen, I’ve already described the most important features of the product from my point of view. What I’ve missed was the actual user interface. I don’t think it will be Siri. In my opinion, usage of antropomorphic user agents can only be accepted by the users in the situations where a human being is also thinkable. For example, I can use Siri-like UI to schedule an appointment, or to be consulted about the best investment strategy, or to find a potential source of foodporn pictures around me. I cannot find Siri useful when I need to add three long numbers, to turn a car to the left when driving on a highway, or to switch channels or change TV set volume.

In my guess I was trying to analyse what has already been done with the iPhone. Question: how selecting a music title was implemented before the iPhone? You had an item list, one item has been shown selected, and you had two buttons up and down to change the selection, and OK to apply. What has changed? In the iPhone, you can now use the second best natural way of selecting an item for a human being, which is directly based and derived from our anatomy and the history of the development of our biological kind. The touching. Note that the most natural way would be grabbing. But they didn’t have technology to implement it yet. Recent announcements hint that there is a lot of research currently in this area. We will hear about touchable displays changing their surface quite soon.

Alas, this can’t be applied for the TV sets, because they stand too far from where I sit. Therefore I can see only two possibilities. The first one is to move TV sets in the 2 feet distance so that they still can be touched. Imagine a couch for 2 or 3 persons, a coffee table before it, and a veeery long (cinemascope format or longer) TV set staying on it. This will still allow for a some social watching experience (one of the most important factors differentiating TV sets from big iPads). The UI would have to be made in the way that it works no matter where you put your first touch. For example, on the first touch, a flower of possible actions appears at this place, and you work from there. This might sound and look a little weird, but compare your experience in a cinema (expecially if you sit in one of the first five rows), where you also have to move your head to watch across the whole action space. This isn’t that much different.

Another possibility is to leave the TV set where it is – relatively far away – and to use the third best humanly natural way of interaction. The pointing. This is different from Kinect insofar that you see an avatar of your palm when using Kinect. This reduces the ergonomics of interaction, first because the virtual palm reacts with quite a big latency on your movements, so you have to get used to it, and second and most important, because you stop feeling your hand as interacting with some object on the screen. After establishing the initial contact with the virtual palm, one could turn off the light in the room so that you wouldn’t know where your hand actualy is, and with Kinect this won’t prevent you from manipulating the virtual palm, because virtually, in your mind, you have replaced your actual palm with the virtual one.

Pointing would work differently. Imagine a situation where you are presented with several running videos on the screen, and you want to select one of it to watch it in fullscreen. You point on it, just like how you would have pointed on it telling your friend “look, there, isn’t that cool”, and the TV set will recognize this gesture and react on it.

I have no idea why is isn’t implemented with Kinect yet. Perhaps there are some technological limitations, or I’m too optimistic about the actual accuracy human beings can have when pointing to a something as distant as 10 feet from them…

Anyways, let’s wait and see what will happen on WWDC. And I want to repeat myself: if Apple won’t announce an iScreen (or something similar) in this year, this might be their first step into decline. Microsoft and Google are already running with all their speed.

This Week in Twitter

  • On WWDC, Apple will either announce their solution to TV problem, or will make their first step to decline. It is their last chance now. #
  • Yet another chance for everybody to start using a password safe and generator (if not using yet). I'm using KeePass. #LinkedIn #facepalm #
  • Ade, Firma Metz! Alles Gute, Labor-FS und danke für den Fernseher :) http://t.co/P2Yo5Ome #
  • ????????????:My Immortal http://t.co/3AhTvvJh #
  • Did you know about the git add –patch feature??? http://t.co/asb8n8Eo #
  • last.fm and eHarmony join the epic fail of LinkedIn. Change your passwords ASAP, and never use the same pw on different services. #
  • If your LinkedIn, last.fm or eHarmony password is used in any other services, you have to go to each of them and change the password too! #
  • And, if you're thinking about using a password safe, use a trusted one, don't just download any. I'd trust 1password or keepass. #
  • ???????? ??????????? ??? ??????? ????????????, ??????? ??? ??????? ?????? ????? ??? ????? ?????? ??? ??????? ? ?????????????. #
  • Yours truly, a slowpoke, just realized one can use HTML/CSS, JavaScript, or XAML, C#, or C++ to develop Win8 Metro apps. Now this is cool. #
  • http://t.co/RlMZ0gS1 reacts to the recent last.fm and linkedin fuckups, preventively resets all passwords. Start using a password safe TODAY #
  • ???????? #

Powered by Twitter Tools

TV Made in Germany

Yesterday I became a proud owner of Metz Carat (which is a special edition device similar to Chorus Manufakturkonzept). For this post, I’ve decided to pick a competitor’s TV in the same price range (around 800 €, note that I’ve got a special employee price for the Carat), which happens to be LG 42LW570S, and to compare the features. The comparison speaks for itself.

Main Features (as in sales prospects)

Screen size
Metz: 37 inch
LG: 42 inch

Display type
Metz: LCD
LG: LCD-LED

Framerate
(This is more a marketing number than something technically clean and useful, but still interesting to compare)
Metz: 200 Hz
LG: 600 Hz

3D Support
Metz: no
LG: yes, shutter-glasses inclusive

Integrated DVR
Metz: yes (see below)
LG: yes (see below)

Smart TV
Metz: yes (see below)
LG: yes (see below)

Detailed features

Tuner
Metz: two independent triple-tuners (PIP is possible, recording and watching other channel is possible)
LG: one triple-tuner

CI+ Slot
Metz: two independent slots (recording one CI+ channel and watching another one is possible)
LG: one slot

DVR
Metz: integrated 500 Gb HDD drive (I estimate around 60 hours of HD recordings), which is also used for timeshift. Recording on externally attached USB drive possible. Export of recordings to external drive possible.
LG: User’s Manual is not clear whether you have to attach an external USB storage, or has the TV an integrated storage. In any case, recording duration is limited by 5 hours. No export.

Inputs
Metz: 4x HDMI, SCART, FBAS, 2x USB, LAN
LG: 4x HDMI, SCART, FBAS, 2x USB, LAN

Hbb-TV
Metz: yes
LG: yes

DLNA
Metz: DMP (expect more to be announced on the IFA)
LG: DMP and DMR

Internet Apps
Metz: CE-HTML and HTML5 apps possible with a software update (expect more to be announced on the IFA)
LG: free web browsing, an own CE-HTML portal, as well as downloadable LG apps

Media Playback
Metz: MPEG1/2, H.264, AAC, MP3, OGG, WMA.
LG: all of the above, plus VC-1, WMA9 and DivX, XVid.

Video on Demand
Metz: none yet
LG: at least two VoD providers (vod.divx.com and maxdome.de), supposedly either WMDRM10 or PlayReady supported

Remote Control
Metz: stable and heavy brushed aluminium traditional remote control
LG: cheap plastic looking remote control with innovative gesture control

Soft features

Geekiness
Metz: a very geeky UI allowing you to configure a lot of very technical settings. Just two examples: when scanning for DVB-C services, you can setup up to three symbol rates (don’t ask me what is this); when configuring display brightness, you have the choices of automatic, manual, dependent on current picture (dynamic contrast), dependent on the room luminance, and dependent both on current picture and room luminance. There are also a lot of features. For example, many settings (eg. volume, sharpness, saturation, zoom level etc) can be set per-channel. The remote control has programmable buttons labeled F1, F2 and F3. And, especially for the older geeks, there is a file manager looking just like Norton Commander (but in gray).
LG: Hard to say just looking at the manual, but it looks more along the lines of a very average and usual modern TV UI (hard to tell the difference between LG, Philips and Samsung).

Image quality
I suppose Metz and LG are very similar in terms of the display panel used. The only difference could theoretically be in video processing algorithms, but the only information I have is that they have 600 Hz of something versus ours 200 Hz. It is hard to say without the possibility to compare the products in a direct test. The only thing I can surely say is that Metz produces truly stunning quality when switched to the “brilliant” mode and tuned on a HD service. The colors and sharpness are even a little exaggerated in comparison with the real-world objects situated left and right from the TV device. And yes, this is absolutely in no comparison with any Internet video stream I’ve ever played on my Acer 27 inch FullHD monitor.

Sound quality
Again, hard to compare without a direct test. Metz won some of the comparisons according to Stiftung Warentest. I don’t remember a similar test result for LG. I’ve even found a 7-band equalizer in the settings. No wonder knowing the persons in charge (hi, Burkhard and Alex) and how they absolutely passionate about the sound.

Future-Readiness
Metz: currently mostly focused on traditional TV uses (receiving digital and analog television as well as playing DVD and BluRays)
LG: Traditional TV is only the half of the user’s manual, the other half is Entertainment section comprising Hbb-TV, web browsing, downloadable Apps as well as integration with second screen devices.

Reliability
Metz: I’ve witnessed a one-hour discussion related to some parts that can break after 10 years of usage, according to the conducted aging tests. The topic was that 10 years it critically low, and the software had to be changed drastically to eliminate the very possibility of damage.
LG: I have no idea. Suppose they will survive 10 years too (with some minor breaks)

The Made in Germany factor
Metz: yes
LG: no

For me personally, Metz Carat is the clear winner, because it runs the software I was co-developing :) As for the market as a whole, the opinions may differ depending with whom you talk.

This Week in Twitter

  • Remember my red box test? Just look how a red triangle is made, and you'll be convinced HTML/CSS should burn in hell. http://t.co/UWbwDz7D #
  • @eldarmurtazin TVersity #
  • Just posted a photo http://t.co/NqIjWmUV #
  • Congrats to @microsoft RT Amazon Instant Video Comes to Xbox 360 http://t.co/12X8cSPH #
  • I FOUND IT! After last 3 weeks of kernel space debugging, after several man/months of search… The bug is fixed now. #
  • @eldarmurtazin ??? ????? ?????? ??????????? – ???????, ??? win8 ????? ?? ??? ?????, ??? ??????? ? ??????? ???????. #

Powered by Twitter Tools

Transcoding for Smart TV

Sometimes, the world of Internet video on demand looks down on the TV. After all, in the Internet, users have the choice of 50 to 120 thousands of items to watch, 1000 times more than on PayTV or 10 times more than in DVD rental.

But, the internet video is still lacking fidelity. Here is how you should transcode if you want to provide most value for your Smart TV users and to target as wide audience as possible:

  • If possible, do not use DVD as your source. Use at least BluRay sources, or request transcoding from mezzanine files. Owners of FullHD TV sets will see the difference and thank you.
  • Absolutely stick with the native framerate. Otherwise the motion compensation logic in the TV set can be confused.
  • For HD videos, try to use the bitrate of at least 6 Mbps VBR with 1920 x 1080p. If you support several bitrates per item, you should absolutely have a 12 Mbps VBR with 1920 x 1080p.
  • H.264 is the video codec of your choice. Period.
  • AAC or AAC+ is your audio codec. Do not economize on audio bitrate either; 384 kbps should be your minimum for stereo AAC.
  • If you want to experiment with multichannel sound, use AC3. It is old, but a lot of TV sets do not support newer formats.
  • If possible, use MPEG2 Transport Stream as your container format. It has the .TS extension, and should not be confused with M2TS (also known as MTS). If TS is not possible, use MP4.
  • By not using any DRM you will widen the possible choice of TV sets capable of playing your stream. If you have a content provider not requiring you to use DRM, consider yourself very lucky. If you are forced to use DRM, stick with PlayReady. Marlin might play some more important role in the future (Marlin and PlayReady are both going to be part of the European HbbTV standard), and perhaps Widevine could be interesting, because it is Google. Other DRMs are not even remotely useful for Smart TVs.
  • Even though video and audio conceptually appear to be two parallel streams in the container, in reality when looking at the physical bytes, you have of course chunks of video interspersed with chunks of audio. Ensure that the longest chunk does not exceed 1 to 2 seconds of payload. Eg. “1 second video”, “1 second audio”, “1 second video”, “1 second audio” in the file is OK. “5 seconds video”, “5 seconds audio”, “5 seconds video”, “5 seconds audio” is not OK.
  • Do not have anything important in the first five seconds. Not every TV set will be able to start the playback from the very first frame. In some TV sets, audio will be unmuted only one second after beginning. This is usually an issue with short news clips or various talk shows that are cut so agressively that they tend to say a lot of things in the first second of video.
  • Do not have anything important in the last five seconds. Some TV sets are sometimes not able to play the last several seconds (the hardware video decoder would prematurely report to be finished). This is usually an issue for agressively cut advertisements, putting the most important information (the name of product being advertized, for example) in the last two seconds.
  • Summarizing the previous two bulletpoints: a) video clips shorter than 10 seconds have very good chances of not being played at all, b) do not cut agressively, insert several seconds of black before and after your video.
  • Use an actual hardware device to QA your transcoding. Software players such as WMP or VLAN are much more robust and forgiving to format errors than hardware decoders.

This Week in Twitter

  • from now on ????? ????????????? ???, ??? ????????? ????????? "????? ??????" ????. ? ????????? ??????? ??????????? ?????????? ? ??????? ? ??. #
  • Fascinating, how inventive parasites are. http://t.co/f9H0hCwD #
  • Third kernel-space debugging week in a row, figuring out how an undocumented hw H.264 decoder behaves. Dejavu, again problems with seek. #
  • is thanking God for this wonderful present! #
  • @bobuk ?? ??????????, ??? ????? ??????????? #

Powered by Twitter Tools

Push-Pull Tactics

1.

Microsoft: we will equip our tablet PCs with pens so that one can precisely manupulate them. And, we don’t need to re-write our software.
Apple: (quietly scheming)
Google: uhm, what? Tables PCs?

2.

Apple: Hey, we’ve made this amazing revolutionary device, and guess what, you don’t need a pen to use it, just use your fricking fingers!
Google: SHIT (throwing out in the last moment the hardware keyboard from the first Android device)
Microsoft: What!? This is ridiculous! This will never work!

3.

Google: (proudly) We have now billions of different virtual keyboards, including such gems as Swype, SCUT and Messageasy. Enjoy your virtual typing experience!
Microsoft: Hey, look how we have crumpled the eight version of our OS! You can now use fingers when using it! (Well sorta. If somebody will write a Metro app for your task.)
Apple: (quietly scheming)

4.

Apple: Hey, we’ve made this amazing revolutionary pen, now you can interact with your retina device as precisely as possible for a human hand!
Microsoft, Google: WHAT!?