Sightseeing in Czechia

Czechia

A couple years ago we visited two cities in Czechia. Here are some of our favorite places in no particular order.

Brno

Super Panda Circus

The most amazing drinks and experience. Just go here!

Šilingrovo nám. 257/3, 602 00 Brno-střed, Czechia

https://goo.gl/maps/t6qRGhvzWi44qs2u8

Atelier Bar & Bistro

A place that makes you feel at home even when you are so far away from home. Wonderful food, fun, and atmosphere. 

2 Kobližná, 71, Brno-město, 602 00 Brno, Czechia

https://goo.gl/maps/3ALiVRyAJqzFHVXS8

Atomic Astronomical Clock

According to wikipedia, "Every day at 11:00 it releases a glass marble, which the spectators can catch from one of four openings in the monument and they can take it with them as a souvenir." Someone might want to add that the locals know the spots and get there early so its not easy to get one, but it's a fun thing either way.

2 Kobližná, 71, Brno-město, 602 00 Brno, Czechia

https://goo.gl/maps/3ALiVRyAJqzFHVXS8

Prague

There is so much within walking distance, but we also made use of the street cars which were a great system. Be sure to download the app for the street car ahead of time so you can get tickets easily from your phone.

Cat Cafes

CatCafePrague

The best cats and chill experience. The experience here is about what matters: the cats. Yes they have the cafe things, but that’s not the focus. It’s a modest space, but there are multiple rooms full of cats. If you have a long time to hang out this is the place!

20, Gorazdova 332, Nové Město, 120 00 Praha, Czechia

https://goo.gl/maps/roU1AHV93PgkjDg96

Cat Café in Smíchov (Kočičí kavárna na Smíchově) 

The cat tree in the back room is worth a look. Some wonderful cats! We were there late one night and the staff was amazing. The menu has a section about the cats that reside there.

Vodní 567/7, 150 00 Praha 5-Smíchov, Czechia

https://goo.gl/maps/9XnvdPxKAX15m2cv9

Kavárna Kočičí Praha 

A really good cafe that has cats. The menu highlights the cats that reside there. A great spot to stop in to begin your day.

Michalská 430/3, 110 00 Staré Město, Czechia

https://g.page/kavarnakocici?share

Puma place

Seriously, pumas. This is still on my list of things to do, but the owners have three pumas and you can get a drink and see them.

Kunětická 2534, 120 00 Praha 2-Vinohrady, Czechia

https://goo.gl/maps/aUeReaiN1zJ9fymW6

OTHER

Invisible Exhibition (Neviditelná výstava)

Experience what it is to be completely without sight. Exhibits are in total darkness and your guide takes you through shopping, crossing the street, and buying a drink without vision.

Karlovo nám. 1/23, 120 00 Nové Město, Czechia

https://goo.gl/maps/Ty2V34dJMHC5Ykb56

BOOKS

The Globe Bookstore And Café — Connected to what might be a food/drink/performance space I just enjoyed the books. The name of course drew me in, but this small bookstore is rich with curation.

Pštrossova 6, 110 00 Nové Město, Czechia

https://goo.gl/maps/vBF3xJNS7rn6ZHJJA

Knihkupectví Meander — Small Book store and publisher. Wonderful staff and beautiful books. If you’re in the area it’s very worth it though I’m not sure I’d trek there just to see it.

Vratislavova 74/7, 128 00 Praha 2-Vyšehrad, Czechia

https://goo.gl/maps/K2F6ggFitHkLqk6L6

Drinks

The Alchemist Bar

While you may stop in and merely find a light filled elegant sitting room with fine cocktails, come on the right night and your fate will be told by tarot resulting in a matched cocktail. Call ahead and be sure that your fate can be told the night you visit.

Provaznická 386, 110 00 Staré Město, Czechia

https://goo.gl/maps/drZsW12Zu8Qsveyq5

Anonymous Bar

All of the cocktails have a fun presentation and after your first round you may discover a secret menu. 

12, Michalská 432, Staré Město, 110 00 Praha, Czechia

https://g.page/anonymous_bar?share

Absintherie 

A small shop with surreal impressionist inspired murals. Go for the table service absinthe which comes with fun presentation.

U Radnice 13/8, 110 00 Staré Město, Czechia

https://goo.gl/maps/HRM1KtWanFB8b4RD7

Kafka

World of Franz Kafka

More about the spirit of Kafka’s writing than about him exactly. It is a strange experience underground. Many of the details from the exhibit exist around Prague but you’ll be left wondering what is real.

Nám. Franze Kafky 16/1, 110 00 Staré Město, Czechia

https://goo.gl/maps/LvfUyEvBLcUkomzU8

Kafka Museum (Muzeum Franze Kafky)

Tells the story of Kafka’s life. If you’re a fan of his I recommend it.

Cihelná 635, 118 00 Malá Strana, Czechia

https://goo.gl/maps/yFDZm4QaTruGZSpw5

Food

U Dvou koček (three cats)

Fun cat murals and there’s a link here to the “World of Franz Kafka” experience. Stop by for a beer or a simple traditional meal.

Uhelný trh 415, 110 00 Staré Město, Czechia

https://goo.gl/maps/tRPRw5JFW9E841j98

Lehká hlava - vegetarian restaurant

The best vegetarian food in Prague! I typically refuse to go back to a place while on vacation because I want to try a new place but we had to go back for a second meal since we enjoyed the first so much. There are two locations: one further North which is more elegant and one to the South which is a little more like a cafe. Both are great, but the one in the North was the favorite.

Boršov 280/2, 110 00 Staré Město, Czechia

https://g.page/lehkahlava?share

ART

Karel Zeman Museum

A museum about the special effects of an amazing artist. There’s a bit of a focus on kids at the museum but we loved seeing the movies and the space. 

Saská 520/3, 118 00 Malá Strana, Czechia

https://g.page/muzeumkarlazemana?share

Illusion Art Museum Prague

Yes, it’s in old town square and a touristy thing, but it’s fun!

Staroměstské nám. 480/24, 110 00 Staré Město, Czechia

https://g.page/iamprague?share

National Marionette Theatre 

Did you know Prague is the center of marionettes? Neither did we but this was such a fun show. Go for the backstage experience if you can. You get to play with the marionettes!

Žatecká 98/1, 110 00 Josefov, Czechia

https://g.page/NationalMarionetteTheatre?share

Marionety

A great little marionette shop of all hand made local work.

U Lužického semináře 83/9, 118 00 Malá Strana, Czechia

https://goo.gl/maps/gFoy9dpvaoMrEiwt9

Art cz Gallery

The dolls in this shop are just amazing. All hand made and stupid expensive.

Prokopská 376/5, 118 00 Malá Strana, Czechia

https://goo.gl/maps/6MGXMLv146QkBaeU7

Cross Club

The night scene here is probably amazing, but I’m an old man so I showed up midday to check out the amazing inside and outside steam-punk decor and to watch an amazing puppet show in the attic. Lunch was great too, so plan a meal at the restaurant. Worth the trip out to the area and if you go the DOX is nearby.

Plynární 1096, 170 00 Praha 7-Holešovice, Czechia

https://goo.gl/maps/2W1w9Nx5hgk14PMm7

Speculum Alchemiae 

Prague has an amazing history with alchemy and this tour is the best. Hopefully you get the same guide we had if you go. It’s a lab that was found under the street when the street caved in recently.

Haštalská 1, 110 00 Staré Město, Czechia

https://goo.gl/maps/pDKxZnhvjwZq69vv7

Museum of miniatures

A small museum about miniatures. They are impressive though the place is remote so only worth the trek if miniatures are your thing. You might be happy enough looking at online photos of the miniatures.

Strahovské nádvoří 11, 118 00 Praha 1, Czechia

https://g.page/muzeumminiatur?share

Uličnická Galerie

An abandoned building who’s front wall became a gallery when someone put a gallery sign on it amongst the street art. Not a lot to see, but I love the idea.

Dukelských Hrdinů 522, 170 00 Praha 7-Holešovice, Cz

https://goo.gl/maps/SRsecnfmc5mxTjvNA

DOX Centre for Contemporary Art

Contemporary modern art museum. The space itself is worth the visit from an architectural perspective. The rotating exhibitions were all wonderful, but not applicable for another visit so I will just point you to the Zeppelin experience within.

Poupětova 1, 170 00 Praha 7-Holešovice, Czechia

https://goo.gl/maps/fex12Q57RQECswK3A

Importing photos from Apple Photos to Adobe Lightroom Classic

I've been really disappointed with Big Sur (Mac OS v11). Neither the 11.1 or 11.2 release have allowed my laptop to  work correctly with my Apple Thunderbolt display and there have been various little bugs that should have been fixed by a .2 release. What really made my decision to move away from it though was how Apple continuously obfuscates your data files. I think it is smart to have collection folders like the Photos Library that look to the average user like one file, but for the advanced user you can go inside and find your files nicely organized. Now though files are in folders buried in within system files and named with what look like GUIDs.

 However there are many reasons to want to transition from Photos to Lightroom. You might have a lot of photos and want to store them on multiple devices (external drives, NAS, etc) and Lightroom allows you to bring all of those together. Also Photos is really great with a reasonable number of photos but when you have over tens of thousands or even hundreds of thousands photos you need to step it up. Also I read about a compelling workflow for using Photos for your favorite photos that sync to all your devices and keeping your archive in Lightroom.

Whatever your reason for transitioning there is no push button option for Lightroom Classic. For the newer Lightroom that uses cloud storage there is an import from Photos, but Classic only supports the ancient iPhoto. I spent a lot of time looking for a solution and found a really helpful post by BertL. The process wasn't ideal for me (I have mainly JPEGs for which Lightroom doesn't use XMP sidecars), but I saw a comment by Rob Allen that led me to his solution. 

On Rob Allen's blog he has a great write up on his migration process. He put together scripts and though some do not work on newer versions of the Mac OS, he pointed to a Python program, OSXPhotos, that does work well.

Basically what appears below is Rob Allen's process but fleshing out the details a tiny bit for Big Sur. Essential to this process is the OSXPhotos Python program.

Ingredients

• Adobe Lightroom Classic v9.4 (on High Seria, OS v10.13.6)
  
• Apple Photos v6 (on Big Sur, OS v11.2.1)
• exiftool - used by OSXPhotos
• OSXPhotos - extracts files with keyword data from Photos
• collection-creator plugin
  
• Comfort level using Terminal

Recipe

1. Install homebrew using Terminal:
   git -C /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core fetch --unshallow
   
2. Install exiftool - go to https://exiftool.org/ and download and install the MacOS Package.
   
3. Install OSXPhoto. You may be better off using pipx via Terminal as the instructions suggest, but I downloaded the source and then ran setup via Terminal:
   cd Desktop/osxphotos-master
   python3 setup.py install
   
4. Run OSXPhoto. Details of how the Python script command is put together are here. Within this command you'll see that exiftool is being used. This is what I ran in Terminal:
   osxphotos export ~/Desktop/photos --sidecar xmp --keyword-template "PhotosExport>{folder_album(>)}" --exiftool
   
5. Use rsync to copy all of the exported files from my Big Sur computer to an external drive:
   rsync -aE ~/Desktop/photos /Volumes/seagate/photos\ export\ big\ sur\ w\ xif
   
6. Plug in the external drive to the High Seria computer
7. Run Import in Lightroom Classic using the Copy function so that it will take the file from the external drive and copy it to the local drive. I had over 70,000 photos so this took somewhere around 16 hours. I didn't time it and likely you'll have a faster computer than the old one that I run High Seria on.
   
8. Check the keywords in Lightroom Classic. You should see your old keywords along with the folders named "PhotosExport ..." They will arrange in a keyword hierarchy based on the Apple Photos folder structure based on the ">" used during export in step 4.
   
9. In Lightroom rename the keyword "PhotosExport" to "_Keywords To Become Collections". This is necessary for the next step, so that the correct keywords are used as collection names.
   
10. Install and run the Lightroom plug-in, collection-creator. Instructions are on the Git page.
11. Now the keywords will show up as collections with the same hierarchy preserved.
    

Hacking Mac Image Capture for Higher DPI Scans

I have been frustrated that Image Capture (the built in scan and camera tool on the Mac OS) seems to be limited to 600 DPI no matter what your scanner's ability. What also surprised me is when I search for it I can't find anyone else talking about this limitation. 

I do find advice on scanning that says if you want quality don't use the OS or software that came with the scanner and buy third party software like VueScan. While VueScan is amazing software that seems to support every scanner ever made, it is also difficult to use and doesn't integrate automatically into PhotoShop the way Image Capture does.

There may be a really good reason for the 600 DPI limit in Image Capture. Maybe it follows the Apple philosophy of guiding you to the right tools. They assume if you need better than 600 DPI then you should  use more advanced software. But you don't have to if you're comfortable editing a plist file.

The following procedure worked for me and I've scanned dozens of images now at 1,600 DPI using Image Capture without issue. Possibly this is like overclocking and my scanner will die sooner because something is wrong here, so follow this knowing I'm really unsure if this is a good idea.

Here's how to scan at greater than 600 DPI in Image Capture:

0. Be sure to back up the file ahead of time and check your EULA to be sure editing it is legal. (This step is a reminder that your plist file may have zero based arrays.)

1. Find your scanner in the Image Capture settings in the system library folder. Typically this is:

    Macintosh HD > Library > Image Capture > Devices

2. In this folder will be a package for every scanner that your computer connected to. In my case I was looking for "Plustek Scanner". Right click on the package with your scanner name on it and choose "Show package contents".

3. You'll now be looking at the contents of the package. Look for the scanner plist. I'm not sure if it's always the same, but for a few I checked it was always this file:

    Contents > Resources > ScannerProperties.plist

4. Open the file ScannerProperties.plist. It is an XML file, but if you have Xcode it will open it as a plist file. Either way search for the first instance of ICAP_XRESOLUTION. In XML it will look something like this:

5. Notice the array of integers. These correspond to the drop down for DPI in Image Capture. Decide on what you want to add. My scanner supports 1,600 DPI so I decided to add a 1,200 as well. If you are using Xcode be sure to set both the value and the type. The type will default to text so be sure to set it to number. In XML my entry looks like this:

<integer>1200</integer>

<integer>1600</integer>

6. In step five the X DPI is set, so now the Y DPI needs to be set identically. Search the document for the first instance of ICAP_YRESOLUTION and put in the exact same entry you did in this location as you did in step five. Also to note, the order matters.

7. Save the plist file.

8. Open Image Capture and scan with the newly unlocked resolutions.

Mustang BXR Manifold

In the early 2000s I had a website dedicated to my car (naturalaspiration.com) and over the years the most popular part about it was the information I had on it about the intake manifold. I decided to keep some of the information around as a blog post.

BXR Intake Manifold without covers

My car was a 1989 Mustang and the intake manifold was a BXR, which stands for balanced cross ram. The concept was a balanced intake where the air had straight shots to the cylinders. The first advertisement I saw for it had yard sticks hanging out of it to show how straight the paths were. Steve Turner wrote in How To Tune & Modify Your Ford 5.0 Liter Mustang, "taking the tuned runner length, optimized port line of sight, and big airflow capacity to the nth degree, the BXR ... intake ignores most all factory packaging considerations to provide stunning performance."

The BXR is no longer manufactured and I am not a representative of that company. If you need information beyond what you see here, you may find it on this mirror of their old website. If you want to purchase a BXR look on used auto part sites or ebay.

There were three different plenum covers you could choose for the BXR manifold. I choose the hi-torque plenum covers for my Mustang because it was a daily driver and I thought I'd buy the other kinds later. It's interesting being able to inspect the inside of the manifold with just the removal of a three bolts, but the real utility is in the easy of switching covers and transforming the characteristics of the engine. Also, porting and polishing is much easier with removable covers. One thing about the  hi-torque covers and the manifold was it seemed to produce more power at slightly higher RPMs than stock. If you babied the throttle it felt less powerful than stock, but if you got on it, you felt the difference.

Some general advice on installing a BXR.

• Check the engine's computer for error codes (or trouble codes) before you begin.
• If you have aftermarket fuel injectors get the special rails. The fuel rails that came with the manifold kit worked best with stock injectors. There were larger o-rings in the special kit which I needed for my 30 lb. hr. fuel injectors.
• Plan for the extra forward height of the manifold. You'll need more room in the front, so if you have a hood mounted functional ram air kit, it will be in the way. The manifold fits under a stock hood, but there's no extra room.
• Have a crows foot wrench and lots of patience for installing the temperature sensor on the manifold. There's not enough room to work and the manifold is alluminum. You might want to consider a temperature sensor relocation kit. I didn't and I had a difficult time getting it seated so that it was sealed but didn't interfear with the fuel rails.
• Get diagrams of hoses and wires or make sketches before you take it apart.
• Use the fan relocator kit if you have a stock fan and radiator. The clearance looks fine at low RPM, but when you rev the engine, it'll jump forward and the fan will attack the raditor.
• The throttle linkage on the BXR isn't clearly explained in the instructions, so I've taken a picture of how it looks installed.

The microS Way

As a conclusion to my notes and reflections on the CA Microservices Conference, I wanted to share the MicroS Way that was presented there.

1. Establish the right boundaries in your code and organization

2. Have a system that balances easy and speed with safety

3. Have the right processes and standards

4. Steer the system and measure it

5. Accept that right, easy, and safe are a product of time and context

MicroS - lessons learned part 3

This is a continuation on my notes from (and reflections on) the CA conference on microservices.

How to Change

Use shock and awe to make change. Be a little outrageous. Do not pivot by spinning on your heel --sprint with a two-by-four, slam it in the ground, and spin round to a new direction. An enterprise is about maintaining stability, so it won't change just because you casually mention it. You need to prove this change is happening and motivate the teams. Have a crazy challenge motivator.

And make the rules of change embody your bold statement. For instance, Gilt moved to microservices by saying you cannot use the main database or commit to the Ruby on Rails depo. These two rules helped to build a completely autonomous system. The trick is to find something simple that forces a new direction.

Besides changing the technology focus, change the way you frame the problem. Gilt doesn't say "do this" but instead gets the best out of a team by asking, "how do you solve this?" You want to tell your team where you are headed, but not how to get there. This is partly because it encourages inguinity, but also because the people on the ground floor always have great knowledge of how things work. Even if management rises from within things can change and those that know the day-to-day need to be consulted.

Another way to get the best out of a team is to have the right team skills. Agile teaches that you put the key players on the team. You choose the engineers and developers that have the skills for the software and technology that you need. The expertise is built within the team so they don't have to reach out and wait for someone outside the team to have the time to help. But there's an expertise that can be overlooked in the team: the business. Having close allignment with the business is automatic when someone with business background sits as a member of the team. Furthermore that person will gain an understanding of the pressures on IT so that the whole team can make wise decisions on what is both business valuable, but not shortsighted of long term IT cost.

Part of long term IT cost is the fact that once something exists it seems to be able to justify its continued existence based only on the fact that it exists. "Someone might need it" justifies going to large cost to maintain an unnecessary system, while half of that cost will not be spent to build a necessary system if it does not exist yet. There are very human reasons for thinking this way that all of us are prone to. The way to combat this natural tendency is to have a Sunset Team. This team is charged with responsibily shutting down systems that are no longer needed. The entire organization should celebrate shutting down an old service as much as they celebrate a new one.


Building Teams

It can sound easy to just put together a team, but there is a lot to consider. Besides what I already spoke to about having the right skills on the team there is also attitude and size to consider. At the conference a team size of four to five people and a department size of around 20 was recommended. If you do not have at least ten engineers working on microS, then your group likely won't be able to handle the increased overhead that comes with microS. As for choosing the people watch how they naturally gravitate to each other. For instance, watch for those that want to work on the new and shiny stuff versus those that want to build a solid infrastructure that is hardened. Put them in separate teams and give them the projects that fit them best.

But do not build new teams and ask them to build microS right from the start. The team should always better understand the work than the technology. In other words you can be new to building a shopping cart, but you better be experienced in building websites and never vice-versa. Your first microS should be ones that you build to solve a business problem that your team already understands. Always know the business better than the technology.

One reason for knowing the technology better than the business is that debugging is always more difficult with something you do not know. This is especially true of microS, but true of anything. If you know the business part well you at least have a firm understanding of what going right means even if you don't know why something is going wrong when a bug emerges.

Focus on team culture. Change that goes against the culture will not be lasting and likely will not even take place. It is an attitude challenge. Culture can cause a team that always codes in Java to write Python as if it were Java. Changing technology does not change culture. Over time a balance will grow in a group between culture, technology, and structure. When you change one the balance is lost, but the group will try to find the balance they once knew by modifying the other two to make up for the change in the one. Unless of course the change to all three is thought out and the team is properly prepared for it.

You properly prepare by knowing that these three steps must happen in this order:

1. The technology and culture is stabilized. Things in flux are actually less able to change because everyone recognizes that the last thing you want to do with a shaky house is change the foundation.

2. Optimize them. Once you have stabilized you can build on that and have a better system, which helps motivate the team to believe in their ability to create effective change.

3. Transform them. Now you are ready for real change.


Embrace Change and Risk

I wrote in a previous post about how to talk about failure. Netflix has a great culture that embraces this at all levels. The fact that they can openly talk about Quickster proves they understand that innovation comes with risk and the best way to learn from it is to talk about it openly. They trade lessons learned in an open way, which transfers knowledge between teams in a radically better way than in a workplace where competition means not admitting what went wrong or could have been better.

MicroS - lessons learned part 2

At the CA Microservices Conference, Vijay Alagarasan spoke about some anti-patterns. I have reworded them to be patterns to follow and added a couple of my own thoughts.


Automation is Litmus

The litmus test on whether you can handle microS is if you can automate. Automated testing and deployment is key to microS, but beyond that if what you have is not regular enough or so eccentric that automation is not possible then you either still in R&D land or you simply are not ready yet. You do not need to automate everything, but if there is something about the software that inhibits automation then that will be a problem for stability, scale, or your own sanity when problems occur.


Centrally Manage Config

Design a configuration manger. There should be one server (not literally one, you're allowed redundancy) that can send configuration changes to your services. If you don't start from day one then you will be unable to control scale. The time to centrally manage the configuration of a service is when you deploy the first instance. Once you are running 15 instances of it, you are likely to miss an instance when you need to change a setting on it. Just think to the last time you were debugging an issue that was intermittent and you checked everything only to finally discover that one of the servers was configured differently. Sometimes it is obvious, but given that you always assume someone was diligent and set them all up identically you can often overlook that sort of bug. Avoid the headache and always manage configuration centrally.

The one argument you can make against central config is security. As I write this it does occur to me that a malicious actor who merely wanted to reek havoc on your network could do it through the config server, but that is more the case of a disgruntled employee with system knowledge. Chances are your hack is going to be by someone that wants to find their way to something valuable and changing something like a rate limit on an API is not likely to help much. Maybe talk to your security officer about this if you are concerned.


API Gateway

An API Gateway has many benefits. It can reveal a lot about network traffic and help to control it with things like caching, routing, throttling (limiting particular calls), and authorization. It can also help you transition from one version of a service to a another by slowly moving traffic to the new one. For example: consumer A is routed to version 2, but all other consumers are routed to version 1. Then consumer B moves to version 2 and so on. A good version strategy allows you to to introduce new versions of a service with a minimum of risk.

However all of the stability a gateway can offer can be reversed through misuse. Every bit of business logic that works its way into the gateway is a potential production issue. The point of the gateway is to abstract you from the business logic so that you can change your business logic carefully (as mentioned with transitioning to a new version of a service). If the business logic is in the gateway then you cannot change that logic without risking all of your traffic being negatively impacted. There will be some business logic in your gateway, but assume anything you put in there may need to be changed and cause a full system outage. Each IF statement should be put in place with that realization.

I'm unfamiliar with these products, but CA Layer 7 and AWS Mobile Gatway are examples of API Gateways.


Question Every Layer

Abstraction is a useful tool, but it needs to be used purposefully. For instance, having a policy to abstract the connection to every database is not good. Each use of abstraction should be for a strong reason about that particular case. Unnecessary layers should be avoided. A coworker told me "no one ever wants to be the middle man" and you should think of layers like middle men. Most of the objections to middle men are the same reason you don't want extra layers in your software. They introduce complexity and the potential for translation issues, they constrain your message into their terms (admitidly this can be a pro), and they consume resources. People would always rather go to the source, but they will put up for a middle man when there's a good reason. Don't just have an extra layer in place like in Office Space.

Do not separate your layers by bussiness logic, data access, or orchestration. One layer should likely embrace all three of these things. The boundaries of a service should be based on a business solution and not a technical one. You are building services to solve business needs. Being able to switch your database out to another one should not be the guiding star by which you design your services. If you have a good version strategy then that should be all you need for technical changes.

Microservices (microS) - lessons learned part 1

This is a continuation on what I learned from the API Academy's microservices conference. None of these are rules, they are all principles. My personal belief is that the only rule should be to embrace continuous improvement.


wAgile

Holger Reinhardt introduced the concept of wAgile which is a blend of waterfall and agile. On the one hand this sounds like an oxymoron and certainly there were laughs at the term. (A colleague of mine suggested perhaps watgile for WATerfall aGILE would be more successful as a term.) If you consider however how the triad of thesis, antithesis, synthesis works of history works though it makes sense.

The industry started with waterfall which is great for project management and it helps managers place timelines, staffing, and schedules of other projects, but waterfall has the danger of mapping things out in such detail and so far into the future that by the time you get to the end of the project you find it fell victim to the rapid pace of change of technology and business, which did not respect your careful planning. A well planed and executed project that solves a problem that no longer exists is sadly as much a failure as a disorganized one that couldn't even complete.

There have been various solutions to this, but agile is the recent darling of the industry. For startup culture the focus on MVP (minimum viable product), which gives early results means you begin to learn and adapt to your market rapidly. Not having a timeline of more than a few weeks out is fine for a company which isn't entirely sure what the business will be by then. Removing the long term calendar and only deciding on when you will complete the next task vastly increases the accuracy of a developer or engineer's time estimates.

In agile training I picked up the razor for separating a candidate for waterfall from agile, which is to ask where the unknowns are. If you know your technology well and know the business problem well then you can probably have a very successful waterfall project. Waterfall depends on your ability to predict and if you have previous experience that applies to all aspects of the project then you should be able to reasonably predict. However if you are building a new business model with new technology then you will do better with agile.

In the enterprise world though things are rarely so clear. To balance innovation with safety you are likely introducing new technology carefully and not all at once, so it is a partial unknown. The same goes for the business which tends to solve problems with mostly familiar solutions and doesn't jump into completely unknown markets in big ways. Also my experience is that no one likes to hear "we'll be done when we are done."

What wAgile says is do the planning and accept the unknown. You do that with the old trick of padding the schedule, but you do it in a smarter way. If you pad each task or phase on a Gantt chart then invariably the time will get used. If someone is done early they likely have pressures on them to get other work done for the business and they will do that work. Yes, it is time spent productively, but it is not helping to get the project done.

Instead of padding parts within the schedule, Holger says, you pad the entire schedule at the end. Keep every task or part tight without any extra time and try to stick to that. When the inevitable happens though and something does not work as planned or the time allocated was simply not enough then take some time out of the padding at the end of the schedule.


New Technology

How do you keep current with new technology and have standards? On the one hand you want to pick a few tools and make those the standard so everyone can know them well and technology can be reused or repurposed easily. Yet this closes the door on introducing new technology and keeping current.

Gilt does this by having an architecture board that brings various groups together to talk about what works and what doesn't. They celebrate when you try and fail (more on that below), because that is how you learn and you cannot innovate without trying new things. The process is to drive consensus on the standards.

There was support at the conference for what I believe is also Amazon's take on this. The policy should be if you adhere to standards you can expect full support. So things like monitoring, off hours support staff, production hardened environments, and infrastructure automation are all available to you. However if you want to code in a new language then all bets are off. If the system crashes at 3 AM you take the phone call and fix it. Sure your colleagues may help you, but you cannot expect it and you certainly cannot complain.

This not only is a policy that allows the introduction of new technology, it is also a policy for retaining key talent. Teams often have a mix of those who constantly play with the latest tech and those who hone their craft on their current skills, but the former will be discouraged if there are no opportunities to use the new tech in their jobs.

When evaluating new technology have metrics on the new and old. If new technology is a narrow improvement then be skeptical. There is a lot of overheard in learning new technology and implementing it which has to be outweighed by the improvement.

I cannot speak to how useful it is, but a few people said that Thought Works' Tech Radar is a good start to conversations on new technology.


How to Talk about Failure

A blameless postmortem is pointless. You need to learn from mistakes, but you need to also accept that everyone is human and mistakes happen. Pointing fingers is not helpful. People need to be encouraged to feel comfortable saying, "it was me, I broke it, and here's how I fixed it." A good programer is one who knows how to recover well from a failure. A programer who hasn't had failures is lucky and lacks that experience needed to handle that inevitable failure when it happens. This is what is at the heart of the concept of "fail quickly" which assumes you will recover quickly. You can only do this in an environment where failure can be discussed openly.