On the Heap

Say No More

stephenzr — Fri, 06 Jan 2012 22:38:33 +0000

Mr. Yeggee is always a blast to read and he’s one of my favorite software pontificators. He bashes Amazon pretty well. Some of his points, though, I’m not too sure about. Others I love. Onwards….

“ They prioritize launching early over everything else, including retention and engineering discipline and a bunch of other stuff that turns out to matter in the long run. So even though it’s given them some competitive advantages in the marketplace, it’s created enough other problems to make it something less than a slam-dunk.”

Why can Google spend so much time on engineering and not release software before it’s really (really) ready as opposed to Amazon launching early at the detriment of everything else? Doesn’t everyone know the answer to this by now? Search is a freaking cash cow. Better than a cash cow. It’s like a printing press for money. Cha-ching, cha-ching! This finances all they do. I’m not the first to point this out though as they are today’s Microsoft. Microsoft has office and windows as their cash cows. Google has search, which at the heart, is just ad’s. Yep, boring old advertising. Nothing exciting here (their engineering and infrastructure and mad algorithms are not part of the product critique.)

Google has launched many products that are miserable. I can’t even remember that piece of crap they had before Google+. But, even that name more or less stinks. And they have Maps, which is really nice, and they are learning to strong-arm business by eliminating their competition in the space by offering a free product but now starting to charge for it.

“Their facilities are dirt-smeared cube farms without a dime spent on decor or common meeting areas. Their pay and benefits suck, “

Amazon may have horrific working conditions, but it can’t be that bad. Honestly, Mr. Yegge is probably long removed from some dude slinging VB at an insurance company in the Chicago suburbs. Yegge is a geek celebrity on the west coast with an extraordinarily high IQ. Amazon appeals to every day people at a personal level, I would argue, better than Google does. Google has no real competitor in Search. Amazon has 1,000’s. Yet, people come back to Amazon consistently because their site works, it’s consistent and they bring you satisfaction.

On the other hand Google helps me find things online. Or maybe maps. Yes, I have gmail, but that is really just inertia and stupidity of Microsoft not to offer the same thing with Hotmail. I’ve never, ever, ever clicked an ad in gmail. Ad’s are for suckers.

“Jeff Bezos is an infamous micro-manager. He micro-manages every single pixel of Amazon’s retail site.”

But so was Steve Jobs and he was adored (adored!) daily and posthumously. Why is Jeff Bezos such a bad guy for micro-managing? I don’t understand why one should be loved and another vilified. One brought ecommerce to the masses and one made beautiful products. I see lots of beauty in Amazon – purchase history, recommendations, responsiveness, breadth and depth of products, etc. Don’t even get me started on how fantastic and open AWS is.

“(SOA) #6, however, was quite real, so people went to work. Bezos assigned a couple of Chief Bulldogs to oversee the effort and ensure forward progress, headed up by Uber-Chief Bear Bulldog Rick Dalzell. Rick is an ex-Army Ranger, West Point Academy graduate, ex-boxer, ex-Chief Torturer slash CIO at Wal*Mart, and is a big genial scary man who used the word “hardened interface” a lot.”

Things could have been worse – Bezo’s could have decreed SOA thus, not followed up and Amazon could have just stagnated as a reseller. Sure, who want’s a hard-ass following you around…I get that.

“because nobody’s mom can use the goddamn website. In fact I myself find the website disturbingly daunting, and I worked there for over half a decade. I’ve just learned to kinda defocus my eyes and concentrate on the million or so pixels near the center of the page above the fold.”

This is where I call shenanigans! Shenanigans damn it! This is total fud, my Mom has been using Amazon for years. Everyone I know uses Amazon. No problems. I go there because it’s better than other ecommerce sites. Somehow it works.

“Google+ is a prime example of our complete failure to understand platforms from the very highest levels of executive leadership (hi Larry, Sergey, Eric, Vic, howdy howdy) down to the very lowest leaf workers (hey yo). We all don’t get it. The Golden Rule of platforms is that you Eat Your Own Dogfood. The Google+ platform is a pathetic afterthought. “

EYOD – yep, Microsoft schools all of you. Google. Facebook. Whomever.

“But when we take the stance that we know how to design the perfect product for everyone, and believe you me, I hear that a lot, then we’re being fools. You can attribute it to arrogance, or naivete, or whatever — it doesn’t matter in the end, because it’s foolishness. There IS no perfect product for everyone.”

Duly noted. Say no more. As always, thank you Steve Yeggee for taking the time to contribute interesting things into this world. It’s better with you.

Silence the Code

stephenzr — Sat, 29 Oct 2011 13:44:01 +0000

Lo! It does cry thus!
Of tangled code and broken
bones – what did the
last
leave
behind?
It smells! It smells!

Of other ideas and coding
styles – Lo, what to do?
I will not touch this, I
will not change this – afraid
I am of this.
I will make -
excuse!
excuse!
I will not take the blame.

Oh, dearest fool – you think it new
for software to have years?
This is life – this work this is
what we’re paid to do.

Make it better, make it cleaner-
make it faster-
no one hears your cry!

Make a change, read a book
talk to a coding peer.
Just don’t lament the broken lines -
you’re responsible for it now.

Enter Scrum

stephenzr — Sun, 18 Sep 2011 01:37:50 +0000

What follows is an excerpt from a longer work chronicling the crazy mishaps and happenings during a one year period at an unnamed, but unfortunately real, company.

————

ABC Corp. won’t be credited for being the inventor of the non-organizing self-organizing team but they at least deserved a spirit reward for the valiant effort in creating total chaos out of a zen like theory on running software projects. You can’t say they didn’t try.Scrum, like some religions, is based on the ideas of one man whose work is subsequently ruined by charlatans, tent revival preachers and true believers. They refer to him as just Ken (Schwaber) and it made Daniel nauseated to watch the process over and over.

It’s based on accountability (which we’ll get into later) and other feel good, rah-rah traits, that an organization with poor management runs to while trying to figure out why their “teams” can’t get it “right”. It’s an easy sell to managers – the concept is that the teams should “self-organize”. It’s like getting paid to manage but not being required to do anything except “assist” or “remove obstacle”.

The most painful part of Scrum at ABC Corp. was sprint planning.

A sprint is supposed to be a given period of time where the development team commits to getting certain pieces of work developed, tested and in shape to possibly ship. For instance, the team agrees to create a login screen. In most organizations this is referred to as a “user story”, as it describes something a customer (user) wants to accomplish. The “story” is given enough detail on paper to get started and then it’s up to the developers, designers, business analyst etc. to complete the concept, development and testing of the feature. It turns it into a team effort. Not so at ABC Corp., which we’ll bullet out for brevity.

1)    Everything is high priority.
2)    Bugs just “need to get fixed”.
3)    There is no plan – no initiatives to group bodies of work. Each item is an individual task.

What’s a task? It could be this “login” story described, or it could be a fix to some spelling on a product page. ABC Corp. management took it farther insisting on a decomposition of tasks down to the sub-atomic particle level – completely bypassing the whole concept of “a team moving a ball down a field” and insisting that everyone sit in a room together, all day, and identify all the tasks that would go into this login screen. A more clever team member who unfortunately ended up in Nowhersville like Daniel coyly commented one day:

“Plan every single task for a two week period up front. Decompose those into very small pieces. Assign those pieces and demand they be completed. Hmm, uh, that sounds kind of like a waterfall approach.”
The other ABC Corp. employees disagreed that it was waterfall, they insisted this the decomposition was necessary so that someone else could pick up those tasks if needed.

A change in management later on made this process even more fun by replacing the white board task decomposition all day activity with forcing each developer to decompose his tasks in their IDE, on their laptop, while sitting in a room full unproductive developers doing the same thing.

Now, Scrum is supposed to be in the Agile camp, hence, Agile methods. ABC Corp. management did not want the technical methods – what they heard was: “we get new features into production every two weeks. That’s what Scrum says.” And surely, they wielded this concept like a sword, slashing through any wary developer, technical manager or CIO without mercy.

Now, onto the accountability of Scrum (or any agile process): the developer was responsible, period. Recall that management of the company believed they had moved to Scrum to get features out faster – if that is the case – why in the world would a feature ever be late or not completed at all. Further, they knew from some random Scrum resources on the internet that developers are supposed to respond to Change. That is a big “C” change – meaning, that it’s ok for a division manager to change his mind mid-sprint, ask for a large change and still have it delivered on time. Again, this is what Scrum tells them.

(To be clear, Scrum is nothing like what is described above or how ABC Corp. did it.)

Distributed Teams Book

stephenzr — Fri, 09 Sep 2011 20:31:02 +0000

It finally published about a month ago. My contribution is a chapter on Trust. Yes, capital T.

Reasons Don’t Matter

stephenzr — Fri, 13 May 2011 16:03:14 +0000

I’ve been reflecting more on the philosophy and practice of Test Driven Development lately. In truth, I’ve not been writing much code the last few months so I’m renewed in the difficulty of getting back into the mindset of writing tests before code. I’m also renewed in spirit of the importance of following such a practice.

Some things I’ve run across recently that has helped get the thought process going again:

1) Re-reading the book The Productive Programmer and his reference to Ocams Razor. The simplest explanation is usually the correct explanation: If testing is the rigor of software engineering then testing has a huge priority. If testing is the largest priority it means it should be addressed paramount. Hence, write tests first.

2) My favorite modern philosopher (whom, I know, I reference far to often) Nassim Nicholas Taleb of Black Swan fame posted on Facebook something to the effect of “If someone gives you more than one reason for something he doesn’t have a real reason…”
What does this have to do with TDD. Well, see my article from a couple years ago – Wrong About TDD – I have a bunch of reasons. Then I come up with more reasons in TDD: Facts and Fallacies. I’m blue in the face with reasons, hubris and general hot air. I have more reasons than fingers. But, according Taleb’s aphorism all of my reasons mean that I may not have a good one.

Taking into account these two findings about my own thinking I vow to rehash my approach to communicating TDD. Maybe not down to just one reason, but probably no more than two – the weary debater can stack the deck with opposing reasons all they like, a large balloon can still be deflated with one pin prick. The reasons are probably better utilized as excuses someone doesn’t want to change as opposed to why they should.

There is more then sufficient confluence in favor of TDD by now. One should learn and practice TDD if they are care about developing working software.

We all must change. This is what we as humans do – we are born to evolve.

Open Source Contribution – Websucker

stephenzr — Sat, 09 Apr 2011 01:21:41 +0000

It may seem a class library like this would be readily available: download a web page, all the assets and alter said web page to reference the downloaded assets. Well, when I needed to build this functionality for 4teaspoons I searched high and low – and not just for .NET code – any code what so ever. No one seems to have to do this. It’s more or less creating caches of a web page. Maybe it’s so simple no one thinks to create a shared library – when that is the case it’s time to contribute the code back to the community.

In my instance I wanted to download a given page and save the HTML file and all assets up to Amazon S3. This library comes with the S3 provider. A provider class can be created to persist the assets just about anywhere – database, mongodb, filesystem, etc. It’s really up to the developer what they need. I’ve taken care of the heavy lifting of parsing the pages and doing the transformation.

I hope this contribution is worthwhile and used.

https://code.google.com/p/ontheheap-websucker/

Why REST over SOAP?

stephenzr — Thu, 17 Mar 2011 18:42:37 +0000

REST all the way right? Or just another absolute software statement that we’ll retract or at least recant over the next few years. I’ve used both REST and SOAP with success, but was posed with the question why use REST?

Good links on the subect:
http://stackoverflow.com/questions/4266466/why-prefer-rest-over-soap

http://www.infoq.com/articles/rest-soap-when-to-use-each

http://www.25hoursaday.com/weblog/2010/08/27/LessonsFromGoogleWaveAndRESTVsSOAPFightingComplexityOfOurOwnChoosing.aspx
“More people need to ask themselves questions like do I really need to use the same type system and data format for business documents AND serialized objects from programming languages?”

https://forums.aws.amazon.com/message.jspa?messageID=43461
The AWS team asking customers why and which API they prefer – REST or SOAP.

I come back to the following: If you want downlevel caching (meaning requests and responses go outside your network, unless you have a very big network), stateless communication and a clean API – prefer REST.

If you’re concern is a couple methods over the wire use SOAP, and if you’re on the Microsoft stack, put it all behind WCF. What about other stacks? I’m open to change this opinion.

On Performance

stephenzr — Tue, 01 Mar 2011 21:27:04 +0000

The concept of good performance versus bad performance has struck me as a little too vague for a while. We had this problem at another ecommerce shop during design and code reviews – “does this perform well?” – but too often it was driven by gut instinct or some held assumptions about a particular technology. There is nothing wrong with gut instinct; it’s a key to being able to make decisive decisions, but maybe not the best for making a series of informed decisions to improve a product or delivery to a customer over the long term.

Serendipitously, last fall I opened of a copy of Communications of the ACM and found a great two part series on “thinking clearly” about performance which really helped clarify concrete items to look at from a design and architecture view (I like metrics, so that helps.)

From there I was able to help our team start looking less at a general performance feeling, but considering real response time and throughput to understand concurrency and capacity. These concepts present a dichotomy in traditional computing architectures so dissecting each separately, and then bring them back together is helpful. The links below present this much better than I.

On the web, and especially ecommerce, we have to focus a very critical eye on the whole delivery chain to the customer/user/browser: First Byte server response times, content download, load distribution, CDN configuration, etc.

Over the years I’ve seen very smart developers join our team that simply haven’t had serious web exposure and have been more concerned about a LINQ operator than the fact that there is a queuing delay at the service layer or the JavaScript files are gigantic and not compressed (as a really simple example and not to discredit troublesome code). Or the alternate, when there is too much premature optimization done and project delivery is thrown off.

We had a great peak season from a technology perspective so I want to share these articles as much as possible.

http://cacm.acm.org/magazines/2010/9/98033-thinking-clearly-about-performance-part-1/fulltext

http://cacm.acm.org/magazines/2010/10/99486-thinking-clearly-about-performance-part-2/fulltext

Enjoy.

Distributed Team Book to be Published

stephenzr — Thu, 27 Jan 2011 17:04:37 +0000

I’m excited – I’ve wrapped up the final edits for a book project collaboration I’ve been part of. The title of the upcoming release is: Distributed Team Collaboration in Organizations: Emerging Tools and Practices, due to publish this spring.

I was very eager, and humbled, to participate in this project when Dr. Kathleen Milhauser invited my chapter submission in late 2009. I had already been working on distributed teams for about 7 years (with and without offshore teammates), was interested in the topic of trust and jumped in. It was much tougher than I anticipated – there is a wealth of knowledge out there concerning trust, but much less on distributed team members – which is why I think this book will be well received.

My hope is that this book is a contribution to the team management and software architecture community and the on going dialog. Expanding our understanding of how members of a team are built up, fit in and are cared for can lead to varied decisions throughout the life-cycle of a project.

At the end I’m quite pleased with my chapter, which covers: trust is in a professional setting, incongruent teams, agitators to building trust, induction problems, and socio-emotional needs, amongst others. There are many other great contributed chapters including technological changes for distributed teams, executive overviews and more.

Special thanks to my wife and my encouraging colleague Krams Ramasubramanian.

Barely Trying – Part 2; Rise of the Middle Tier Programmer

stephenzr — Fri, 21 Jan 2011 04:26:49 +0000

What started as a full rebuttal to the Reddit comments of my last essay has turned into something simpler and hopefully more engaging. After all, forums like Reddit provide both the constructive and destructive comments that can change a mindset, like a mob, but a tad less violent. In this way I’ll bullet out the easily addressable and then end quickly with a visual of the system dynamic I alluded to in my last post.

Response

My points on having a system view of a software or IT shop are at least somewhat validated by the pedantic nature of some replies. Missing the forest for the trees is the whole nature of system dynamics ignorance.
I didn’t make this point clear enough. In a horribly stereotyping way, there are two different types of programmers and management philosophies:
- 1) Any programmer can do any programming job.
- 2) Specific task at hand, budget constrained, maintenance, long term technicals skills of company; maximizing early efficacy
- My instance was #2.
Hiring bad programmers death spiral. Please see this essay for an example.
Some Reddit responders were angry at a purported elitest tone of the last essay, yet, Microsoft (in the day, Showstopers!), Facebook, Google, etc. have all focused an almost elitist attitude at hiring great talent. Joel (on finding great developers for his shop) does the same. Responders showed an alternate hypocrisy explaining that they are so talented, so versatile, they don’t need to know what a factory is. Of course, as I readily admit, seeing one’s own faults is much more difficult than pointing out others.
Objections to knowing what a “factory” is are completely warrant-less if the job is OO and on Java or C#. This is the one of the biggest problems with the software industry – people can’t rally around practices. Imagine if doctors didn’t rally around known cures, but kept trying to one up one another (not pharmacology, but treatment). The fine folks at ObjectMentor have been at this for a long time now.

And, lastly, as the anonymity of the Internet is famous for providing, the rest of the comments consisted of ad hominem and straw man arguments, which of course, there is no civil response for.

System View

Now, the system view of the Rise of the Middle Tier programmer. It starts with apathy, which is a self feeding vice, hence and increase of apathy leads to a decrease of knowledge, etc. as the diagram displays. This is a positive (reinforcing) feedback loop. They’re stuck.

This feedback loop needs to be short circuited somewhere. In this example, the apathy is replaced with motivation. There are many things that may trigger this and is entirely up to the individual. I imagine someone waking up realizing they’ve been going into interviews talking about being a middle “tier” programmer and realizing they’re describing a layer of an application and not a tier. Here, the increase in motivation leads to an increase of knowledge, increase of interviewing ability and a decrease of dead end jobs.