CoolBeans

Context

noreply@blogger.com (Anonymous) — Mon, 13 Apr 2015 20:39:00 +0000

The right information at the right time. No less, no more. Only the information pertinent to me, the consumer. One step ahead of search. Control the Context to grow understanding, trust and relationships.

Man In The Arena

noreply@blogger.com (Anonymous) — Mon, 20 Jan 2014 20:03:00 +0000

It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. -Theodore Roosevelt

Full Steam Ahead

noreply@blogger.com (Anonymous) — Mon, 16 Sep 2013 18:54:00 +0000

The History of Programming Languages

noreply@blogger.com (Anonymous) — Mon, 03 Jun 2013 20:46:00 +0000

Infographic by Veracode Application Security

How hard could it be?

noreply@blogger.com (Anonymous) — Thu, 29 Nov 2012 20:33:00 +0000

Crossing the Chasm without Jumping the Shark

Good Morning!

noreply@blogger.com (Anonymous) — Fri, 14 Sep 2012 20:12:00 +0000

Great morning for a car guy, ironically from the seat of my bicycle. First I pass by a mom loading her kid into Fiat 500 Abarth. I stop for a second to hear the car leaving the driveway - and what a sound it makes! This must be the best sounding small car there is, at the moment. Visceral, deep and burbly with ever so present hints of effervescent sparks of crazy - sound.

Then just around the corner, Ford GT in Gulf livery - a guy just getting in. I stop again to watch him backing into the road, stopping all the traffic behind him. The car looks absolutely mint and the guy has a bit of a hard time handling the clutch smoothly without bit of a hop, rumble and supercharger yelp. Then it slowly and majestically disappears around the corner hugging most of the drive lane with its width. What a sight!

Now

Then (1968 Le Mans)

Add Simplicity

noreply@blogger.com (Anonymous) — Sun, 04 Jul 2010 18:50:00 +0000

SIMPLICITY needs to be constantly "added" to software solutions.

It's very easy to create unnecessary complex solutions for variety of reasons. We engineers like to create smart and unique solutions, but can't always see where it is justified to do so. It can easily become an "ego thing" where too much of personality of author creeps into solutions. No one else then fully understands the solution, which becomes increasingly problematic with time.

Today I'm painting my garage. It is 30 degrees Celsius out there and all I want to do is to give the garage a new coat of paint. The builder has decided to add nice mouldings horizontally and vertically - every few feet. These mouldings while nice, increase my effort exponentially, as I have to paint them individually. 30 degrees heat is equivalent to a need to turn a project around quickly - under heat. Luckily I don't have to paint the garage that often, but I'd be in serious trouble had it been my software product.

Another reason for complexity can be just the development landscape. Especially enterprise software can be a mine field of complexity. Variety of implementation technologies, techniques and patterns is augmented by infrastructure as colorful as United Colors of Benetton.

So just to display enterprise grade "Hello World" - what do we need to consider? Front End? Check. Load balancers? Check. Web tier? Check. App Server? Check. Database? Check. ORM? Check. Caching? Check. MQ? Check. EMB? Check. WS-*? Check. A few obscure protocols of choice? Check. Complex transactions? Check. N-Stack for redundancy? Check. One mainframe for "Hello" and another for "World"? Check.

OK, there is more but I'll stop here. The point is that the landscape is complicated as it is. We should not add any more complexity (or "smarts"), we need to strive for the opposite. Simplify, Simplify, Simplify.

It is the same outside of enterprise software. The competition is tough, you need to be constantly adding value and looking for new opportunities. You need to be nimble an light on your feet. Ability to adapt and change is more important than validity of that "Great Idea" you once had.

The formula to success in software business is to Add Simplicity on every step of the way. If you think your killer idea will make your solution successful - dream on. Actually, WAKE UP, you are delusional and it is hurting you. Your idea has already been thought of by someone, somewhere. The difference is in execution.

"Add Lightness" - Colin Chapman

Software Art

noreply@blogger.com (Anonymous) — Sun, 04 Jul 2010 17:36:00 +0000

Software engineering is part science, part art. The science part is all about making computers understand our instructions. Science are the algorithms, languages, execution environments and semantics. The science portion of software is fairly cut and dry and mastering that will give an ability to execute a given task. It is not a difference maker, though.

The "difference maker" is the Art in software. Software Art is all about how do we translate general idea into specific instructions that computers can understand, while losing as little of the original intent as possible.

Software Art is encompassing both What are we solving and How are we doing it, in exact measures of each. Like a good cake recipe. Software Art is the sweet science (doh!) of the Big Picture. It has it own way to affect the final results. The most important property of Software Art is SIMPLICITY.

To be continued ...

noreply@blogger.com (Anonymous) — Tue, 15 Jun 2010 16:01:00 +0000

SOAP, REST, Postmen and Telephones

Once upon a time, SOAP was Simple Object Access Protocol.

That is some 310 characters in simple enough message.
What we want to do is to execute a remote method such as:

Amount getAccountBalance (AccountNumber);

We also wish to ask a specific endpoint:
http://example.org/account for the answer.

The actual ask could be encapsulated in as few as 65 characters.

In this example, our question’s payload grows ~5 times. The reason is that we are not ASKING A QUESTION; we create an intermediate message that does it, including complete explanation of the intent. We than sent the message to the other side, that will do nothing upon receiving the message – there is no business meaning to receiving a message, yet. The receiver has to open the envelope, read the message and reconstruct sender’s intent. Only then can the receiver actually ANSWER the question – but it proceeds to put the ANSWER into yet another vanilla envelop and send it back to the original sender, continuing the cycle.

Consider following scenario: Jane wants to ask John “What time is it?”
A SOAP service could do something like this:

Figure 1 Wait a minute Mr. Postman!

This certainly works, but there is a significant overhead in this style of interaction. Think of all the logistic and recycling needs! Also, there are dangers lurking in the shadows: Ink may dry up. Letterhead paper may run out. Or we maybe out of stamps!

It works, but we could do better..

Imagine a phone conversation:

Figure 2 Mr. Marconi? Hello?

There is no reconstruction of sender’s intent needed, the receiver reacts directly to sender's QUESTION.

This is much like RESTful style

HTTP GET www.john.org/time
HTTP/1.1 OK 200
10 AM

~
The proposition of SOAP style messaging is that it can abstract communication details. SOAP message is a SOAP message is a SOAP message. A letter can travel all around the world. It used to be that letters were the only way how to communicate remotely.

But SOAP also abstracts the actual QUESTIONS. We exchange envelopes of “mysterious content” and reconstruct senders and receivers intent encapsulated within on each respective side. OVER AND OVER AGAIN.

The main benefit I see is that SOAP is transport agnostic. I am not tied to HTTP for my Web services. Is it worth the price? Is the cost benefit justifiable? I don’t think so. Especially when I introduce other WS-* concerns, which snowball INTO my SOAP message, I quickly come to a need for dedicated midle ware, effective compression and transformation mechanisms etc. I’ll take SIMPLICITY, instead.

In RESTful style, we can ask more direct questions. The question is expressed directly to the RESOURCE, not through auxiliary message. There’s little need to keep introducing additional, verbose, xml based mechanism “encapsulate” the QUESTION and make it generic “Message”. Understanding of a Resource IS generic already, just as Jane knows what time is, so she can ask the QUESTION about it.

WS - Reuse - Simplicity - Consistency

noreply@blogger.com (Anonymous) — Mon, 14 Jun 2010 20:36:00 +0000

Reuse in Web Service world. I think about reuse from the perspective of two major architectural styles - Message based (SOAP) and RESTful. It seems to me that SOAP based architecture is poor fit when we aim for REUSE, from its very foundation.

Let's have a look at the building blocks of both styles (pic below), with a bit of a twist. Clearly, SOAP style ignores the full CRUD API of its most usual transport protocol - HTTP. Instead of using full set of HTTP API - GET, POST, PUT and DELETE, it uses POST only - just as transport gimmick.

There maybe some good reasons for this, but what it also inherently means is that this very CRUD capability of HTTP needs to be replicated on the service API - after all CRUD change is what we want to do with the service.
Each service now has to re-implement a definition of CRUD capability by itself! Just by definition of this information interchange, we mandate waste. We do not use what we have and invent something new for the same purpose.

Not only is this an replication and overhead on the service provider side, it also causes an overhead on service consumer side, where each consumer pretend they do not know what they want to do, must "learn" (i.e. discover) the capability set of each service, map it onto their original intent, exchange messages with the service provider and interpret the results. So we have reimplemented the same capability, just made it more complex.

Compare that with simplicity of RESTful approach. No auxiliary messages, no discovery of APIs, each service has the same set of capabilities - HTTP methods. These methods than "transfer" "service state representations" (an instance of resource) from consumer to provider. To know WHERE to transfer and to know WHAT is the relationship of resources - there are URIs, to know HOW to transfer- there're the methods of HTTP. To navigate and relate, there's hypertext. No fancy middle ware needed, short and sweet information exchange using the battle tested infrastructure of WWW.

Now that is some sweet REUSE - SIMPLICITY - CONSISTENCY!

Ford Flex take 2

noreply@blogger.com (Anonymous) — Tue, 27 Apr 2010 18:02:00 +0000

I previously wrote about my experience with driving rented Ford Flex from Toronto to New York and back. There is an UPDATE ... .

2010 Ford Flex Ecoboost now finds home in my driveway. The trusty Duratec 3.5L V6 makes way to a new 3.5L Ecoboost engine. Twin turbocharged, direct injection mill is good for 355 hp and 350 lb ft of twist that is channeled to all four wheels. The ride is lower to the ground, susspension is stiffer, steering wheel feedback (EPAS) is much improved and the 6speed automatic transmission much better match with the engine than in the rented model. The dash issue of glowing see of green buttons I complained about previously is mitigated by large screen navigation system, which is also used to control the sound, climate, phone, 10G of HDD for entertainement or backup camera. Microsoft's SYNC is still doing a great job in providing voice interface to most of the features.

Features galore indeed, but you can always turn most of it off, open the sunroof, push on the steering wheel mounted paddle shifter do drop a gear, step on the gas pedal and ... GO! There's no thinking twice about it anymore, the peak 350 ft lbs of torque are on tap almost instantly (from 1500rpm), pushing you into the seat, while the sprint from 0-60mph comes in just 6.5 seconds. Very quick and effortless. And this is a large seven seater we are talking about! The speed maybe something to get used to, Flex is a very quiet and comfortable car and it is very easy to seamlessy cross into the illegal speed range if not checking the speedo.

Another great aspect of the car is the ability to cross large distance without tiring either the driver or passengers. It is a great family GT car. That kind you can pack all the camping gear into, car seats for the little ones, seat two more adults in comfort (grandparents) and go for a weekend trip without worrying if the destination is couple hundred kilometers closer or further. Or fold all the seats flat and load up half of IKEA into it. Or take all the sippy cups and toys out and go enjoying the on-ramps and back roads. Flex can do it all and do it very well.

From the pen of Jake Maly

noreply@blogger.com (Anonymous) — Wed, 25 Nov 2009 18:31:00 +0000

I pooped well this morning. Halmony washed me up nicely.

I came downstairs sans diaper & pants, and decided to go to wake sleeping Harabujy up.

Harabujy pleasantly woke up by me. Since I was feeling extra happy with the nice bowel movement, I decided to sit on Harabujy’s lap on his bed.

Harabujy and I were chilling. But then something strange & stinky happened behind me. Harabujy and I both got shocked and we started screaming together.

Halmony seems busy today washing lots of things.

Ford Flex Test Drive

noreply@blogger.com (Anonymous) — Wed, 14 Oct 2009 14:55:00 +0000

Spec: 2010 Ford Flex, AWD Limited, 3.5l www.twitpic.com/lhvda

Having an extended family of six and desire for a road trip from Toronto to NYC during Thanksgiving weekend, the trusty '08 Altima was relegated to a driveway rest and we rented a Ford Flex. I was quite intrigued by the vehicle before, so I was quite happy I got to rent it for a long drive.

It's a big car. It feels like a big car inside, it drives like a big car. Lot's of toys inside, Sync is fantastic, great seats, great versatility, good handling and comfort, great HID projectors up front, LEDs in the rear. So many good things that the shortcomings are even more disappointing. In sum, it feels like a two step car. Turn the wheel and wait - it shall turn. Step on the brakes and wait - it shall break. Step on the gas and wait - it shall accelerate. There is no progressin, no modulation. It's on or off. Anemic steering feel negates very solid suspension setup. Lazy (very) 6sp automatic transmition does absolutely no favors to the 262hp V6. The important instruments are too small - speedo. There's a million buttons (so it seems) on the console http://twitpic.com/lhvgi and it does no favours to the driver on a long drive through the night and rain। Great functionality, good fit and finish but lacking ergonomics - I was really distracted by the flowing field of green buttons when needing to adjust temperature and fan speed (toggle+button action) after 4hrs of driving. What's with the single stick with turn signals, highbeams, lowbeams, front wipers rear wipers and windsheeld washer? Couldn't Ford fit even more functions in there :-)?
The writeup may sound a bit negative, but I really like what this the car COULD BE as whole. Great handling, good power, great utility and comfort in a package seating 6 people. If the next iteration fixes some of the issues and puts a bit more GT and refinement into the car (which I hope the EcoBoost version already does, to some extent), I'll put it towards the top of my shopping list for large family car, regardless of make.

Agile Done Right

noreply@blogger.com (Anonymous) — Tue, 08 Sep 2009 18:38:00 +0000

Agile as a software development methodology [http://www.agilealliance.org/]. The empowering of teams, the productivity of team which surpasses combined efforts of individuals. The starter fluid to change and improvement. The results orientation. Constant iterations and reflection. All of it provides tremendous potential for an organization to deliver outstanding results.

It can be a tall order to influence the way an organization works. I work for a large financial institution and rigid, risk averse environments are typically hard to change. But I'm proud that our own "Agile Mix" is successful and finding its way to broader and broader audience. I was the main advocate, proponent and preacher of Agile, at the beginning. Not so lonesome, anymore. Given trust and a seed team, we have not only developed out own "Agile Mix". We have also delivered the product with zero variances detected through out QA, on time, on budget. Our plans and estimates were aggressive and REAL. The team loved working in high paced and stimulating setup. They loved owning the product.

Everybody listens and learns from success stories. There is no better way to convince anybody that Agile works, other than when teams love it, while superb results are delivered.

Agile done right will evolve organically, with thin layer of "impediments removal" on top of it. The core values need to be reiterated and reflected in each team's decision. The particular flavor of Agile - XP, Scrum, Lean doesn't quite matter. All of the different methodologies provide yet another set of tools we can choose from, with useful variation in approach to achieving the same thing.

To make Agile work in any organization, you need results. Go get a team and DO IT. No matter the scale of the project, doing it is the only way to figure out what works in your environment and what doesn't. Your "Agile Mix" will always change and evolve - that's a good thing. Set the expectations right, be 100% transparent with all stakeholders. Apply the same rules on the process, which you'd apply on the product. Iterate. Iterate. Iterate.

My Work

noreply@blogger.com (Anonymous) — Wed, 02 Sep 2009 18:13:00 +0000

Craftsmanship:

The paramount of my efforts is to be a good craftsman. Regardless if I'm replacing a light bulb, designing software, doing R&D, strategic planning or giving presentations and executive summaries. I want my work to be meaningful. I want to know it is making a difference. I want to keep getting better at it. Day in and Day out. [http://manifesto.softwarecraftsmanship.org/]

I like Agile software development methodology very much. It helps in making good craftsmen - it makes work personal. I blog about Agile here.

The rest is some tech stuff I enjoy working with, in no particular order:

Concept Development

Software Architecture

Best Practices

Software Design

Enterprise Portals

J2EE

OOA and OOD

OSGi and all things modular

RIA

Services and SOA

Strategy and Planning

And when the push comes to shove, I lead the technology SWAT team to action on large scale enterprise projects.

Browser as a Platform, HTML 5, WebSockets

noreply@blogger.com (Anonymous) — Wed, 19 Aug 2009 14:44:00 +0000

In 2009 QCon London presentation "Browser as a Platform" Mozilla’s own Ben Galbraith and Dion Almaer presented their view of current state and potentials for the future state-of-the art in pure browser based applications. Very enthusiastic and entertaining presentation, lots of familiar icons and visuals from many organizations, some Bespin tease, all great stuff and fun.

But it got me thinking more about aspects of HTML5 that got very limited spot light (at a bit unfortunate cost of constant comparison to Flash and other plugins) - WebSockets and Server (sent) Events.

WebSockets and Server Events should become the real game changers of the browser world. Rendering technology (HTML DOM and JavaScript) issues and browser issues (threading et al.) are mere growing pains of an infant, but it is when we start looking at (and talking about) full duplex communication capability from the browser (WebSockets) and about standardized browser "PUSH" Comet style (Server Events), we'll know we've reached the maturing phase of an adolescent first class, full fledged presentation technology.

Communication is the key.

HTTP served us great as an information exchange protocol over many years, achieved great standardization and ubiquitous penetration. It enabled new architectural styles such as SOA; it is deeply reflected in REST, among many others. It also held the information flow back a little bit, which could be good and also bad. With browsers, it held it back.

Post-back driven web applications of earlier times, even with AJAX "wizardry" of late have kept the browser from becoming first class player in presentation technologies. Not that there are not great examples to the contrary, there are many amazing applications delivered in plain browser client.

But any first class player has to be able to achieve this in a simple, easy and replicable manner. It maybe simple, it is not always easy and not very often replicable to deliver browser application where user doesn't notice there is a browser involved and is interacting with the system in natural and intuitive way. Applications need to be specially tailored, users need to be trained.

It is the limited information flow paradigm that has held the browser from becoming first class player, capable of delivering of any application to all users, even more than the browser and presentation issues. After all, simpler presentation is often better and as great as Canvas and SVG (RIP?) are, their utility is centered around specialized set of applications.

But in any case, only after the information flows naturally to seamlessly enable application's flow and support user's thought process, can we present the information effectively and without technology infused stops and gaps. That is why I see the changes introduced by WebSockets and Server Events as profound and truly significant additions to the capabilities of browser based applications.

We'll still probably hear more about the presentation aspects, JavaScript Engines and threading tweaks of the next generation browser and standards, but the more we hear, talk and focus on the information flow features, the further stage has been reached on the Hype Cycle of "New" Technology.

OSGi Complexity?

noreply@blogger.com (Anonymous) — Fri, 03 Jul 2009 20:25:00 +0000

Functional decomposition and modularization of applications is a popular topic. Instead of building singular, monolithic applications, we can build little Bundles or Modules that represent business functions and put them together Jigsaw Puzzle style.

The idea is that any overhead of such an approach is greatly offset by the benefits of encapulations - from software development to enterprise function placement.

For example, an application can "Shake bread crumbs with some chicken" and "Bake dinner", these two concerns are agnostic of each other, but can be composed into business flow "Shake 'N Bake". Or other business flows can be "Shake 'N Freez" or "Defrost 'N Bake".

Anytime we need to add/remove/change anything in the application we know exactly the place where the logic lives - as opposed to hunting throughout large codebases of potentially manyy application. It works great for testability, enables effective refactoring and short iterations.

OSGi has done a terrific job in championing of the modular concerns. But OSGi implementation can get quite complicated, for a reason that is not part of its core value proposition ...

Large portion of OSGi complexity comes from the assumption that the whole system is highly dynamic - OSGi bundles can come and go during the runtime and the system needs to constantly adapt. That is great and usefull for certain applications - I imagine telco world is a great example, but for most applications, this ability introduces too much complexity. Take the stallwart of OSGi examples Eclipse - the dynamic bundle update (called Plugins) is not used everyday and most new bundles force restart of the application after update, anyway.

Here's a solution: As soon as I replace "highly dynamic" with "fairly static" environment assumptions, it gets much simpler. I know that my application will either "shake" or "bake" sometime during application's runtime, anyway. I can live without introducing brand new business functions (say brand new operation "DeepFry") while the application is running. Now I could concentrate on the real issue at hand - modularity and functional decomposition, which is the core reason I arrived at OSGi gates.

Most of the OSGi complexity goes away with this change. It is a simple change, but it has far reaching impact. Bundles still have dynamic lifecycle, the major change is that all the Bundles are present from the start of the application and the application doesn't have to deal with Bundles exiting or brand new Bundles entering the application on a whim. Maybe this could be called SimpleOSGi.

Thanks to Ricky Bobby and Cal Naugton Jr. for inspiration in naming business functions examples. Dear Kraft Foods, please do not sue me.

Name Things Right

noreply@blogger.com (Anonymous) — Fri, 03 Jul 2009 18:54:00 +0000

In Object Oriented languages, Class represents a definition of what will become an Object at runtime. In some languages (Smalltalk, Ruby) Class can be a runtime Object as well, in others it is more static formula (Java, C#). It always contains the prescription, the recipe. A Class may say: Add two arms, body, head and two legs to create a Person. It can also say that Person can speak.

When software runs, two instances of Person Object are created and they can speak with each other.We try to model the problem domain which is the target of our software as collection of Objects that can interact with each other (i.e. two Persons can speak with each other). This added level of abstraction helps us understand the domain better – we do not primarily focus on the details of sound wave exchange that is human speech, we primarily focus on the fact that two Persons can speak with each other. This way we do not get lost in details from the start, we find a place to put appropriate logic and move on.

The trick to software modeling is the ability to “Name Things Right”. If I can give names to all the actors in my domain I have created all the Classes. Then I decide what the actors (now Classes) can do in form of methods and I’m done creating my domain model. If I can not name my actors, I do not understand the problem domain enough to try to solve it with software. I have to go back and get more information, remodel and refactor. It takes several iterations before the problem domain is solved.

When “Utility Classes” rear their ugly heads: Utility Classes are convenient holder of unrelated methods, often accessed statically. I’m convinced that proliferation of Utility Classes is evil in Object Oriented software. It is clear indication that we have failed to model our domain correctly and started to put methods into one size fits all bag. Strobe lights should go off and sirens should sound every time this happens – just to attract attention. “Name Things Right” and your design will be conducive for beautiful code to happen.

Hat tip to Derek Zoolander for “Name Things Right” inspiration.

Twitter this, Twitter that II.

noreply@blogger.com (Anonymous) — Fri, 26 Jun 2009 15:13:00 +0000

I found about Michael Jackson's death last night, via Twitter. RIP King of Pop. Even though I never was a proper fan, I think he's been a major factor in the culture of late 20th century. The music will live on.

Suddenly it became a bit clearer what is the magic of Twitter, for me. Information comes to me, I do not actively come to it. I have no idea what I'm going to see each time I open TweetDeck.

This is also known as the Hollywood Principle and IOC . It's used heavily in the software world and the main benefit is the removal of coupling among systems, computers, components, classes or files. One part of system doesn't assume anything about others, it declares its capabilities and lets others use it. The less coupling, the less assumptions, the less plumbing, the cleaner and simpler designs and lesser potential for mistakes. It makes it easier to develop great software. It also makes it easy to understand.

IOC has caused a shift in the software development paradigms and it's also changing the way we digest information in general. Applications like Twitter are trully Inverting the Control of Information flow from "browse and search" to "publish and subscribe".

Twitter may come and go, but it has moved the paradigm shift along a bit. It didn't start the shift, either, there's been bss and newsgroups and rss feeds long before it. I used to think rss is the greatest, just like I do about Twitter, now. Rss reader is still one of the most heavily utilized applications on my smart phone. Twitter is simpler, faster and more engaging. Search results from search.twitter.com are great complement to Google search.

Any (web) application needs to be aware of this shift. Information access needs to be simplified, simplified, simplified. It is not that there's too much of information, it is that it's too tedious to get to. If it's not simple, I'm not interested - and I'll never know how great a product you might have.

What's for lunch

noreply@blogger.com (Anonymous) — Thu, 25 Jun 2009 15:14:00 +0000

That's a reccuring question, every day I forget to "brown bag it". I wish there was a simple way I could be suggested what is the current soup du jour by local eateries. I don't want to perform an extensive (re)search, just recieve short notification that "Wednesday Wings are 20c each @ Lawrence Wings". I wish to receive such notification only on Wednesdays, and only if I'm in the vicinity of Lawrence Wings. Just that and not much else. Sounds both simple enough and exciting to do. Bit of RoR for the web front end, android extension for mobile , Twitter API for the broadcast ... . Why don't I do it?

There are many applications centered on food industry - Urban Spoon, Open Table, Yelp, Menu Palace ... and it's still a hedeache to order pizza online in Toronto (except from PizzaHut, if you are into it). Lot of great apps, but I feel that each is trying to do too many things at once, forgetting to satisfy the ONE need, first and foremost. My need is to find What's for lunch. Period.

I find myself to have lower threshold for the amount of information I'm willing to digest, than I used to have. I want to find what I'm looking for, not much more. I don't browse around much anymore, I search and I'm gone. The one way to make me stick around (and eventually monetize on me) is to give me what I'm looking for first, than weave a web of distraction around it.

STICK TO IT

noreply@blogger.com (Anonymous) — Fri, 29 May 2009 19:25:00 +0000

There are many approaches to designing and developing software. There are even fancy names to each. Structured or Procedural, Data Centric, Domain Driven, Event Driven, Object and Aspect Oriented ... and more. Add any implentation language of choice to the mix and stir well. People may tell you that some are better than other, some are practical, and others are just playgrounds for theory obsessed folks wearing funny hats. Some are old school and others are the new kids on the block. There are as many opinions on what it all means as many people get involved in discussions revolving around these topics. Books have been written, countless presentation were sat through.

We still keep discussing which the best way to build software is. The answer is simple: It doesn't quite matter. Potato, Potatoe. Different hats for different heads. Different tools for ... different folks. I may have mixed up my analogies a bit. Ultimately it is the type of job that has to determine the correct approach (insert another toolbox analogy).

The point is once you've chosen one approach, methodology or philosophy - for a particular task - STICK TO IT. It is the "dog pretending to be a cat" solution that brings out the worst in any given approach, combined. It is because each paradigm can be very different in nature, have different value system, different focus. And these do not mix well, especially if we try to make one look like the other.

The final product may look OK - on the first take, but sure won't taste great (insert the Cat and Dog making a cake tale details). It will have the worst traits from each approach involved, under such circumstances. Our OO code will be overun with inheritance, our Procedures interrupted without any apparent reason, our Domain Objects will not represent any business reality, our Pointcuts will attempt to crosscut accros dimensions.

So show your colors. Wear a 'God thought in Erlang' T-shirt. Spray paint 'Shuttles run on Procedural' all over you cubicle. Be critical but also proud of your decision despite what is the soup du jour. Beautiful code can happen using any approach. Choose what is the best for your team and project and STICK TO IT. Once you are done, re-evaluate your decisions, explore new teritories and get closer to the cutting edge. Then STICK TO THAT until you are done again.

Twitter this, twitter that

noreply@blogger.com (Anonymous) — Fri, 29 May 2009 19:12:00 +0000

As a believer in the goodness of disruptive nature of new *stuff (well, mostly limited tech), I've been following Twitter for quite some time (@danielssonn). Using a cell phone with Windows Mobile (don't ask), good Twitter client is hard to find. Now I want to try the Twikini client, and the good folks are giving 'em for free! All you have to do is publish a blog post, following few simple rules.

Twikini

Kids and books

noreply@blogger.com (Anonymous) — Mon, 04 May 2009 13:55:00 +0000

This morning in the neighborhood was beautiful. Sun was shinning, birds chirping and the tulips blooming in plethora of colours. The neighbour’s son was dragging his huge backpack off the front steps, on the way to school. One of the last generations to have to do this, I hope. Once the time comes for my son Jake, he’ll be travelling light. The word on the street is that Amazon is to announce textbook size Kindle, soon. In the years to come, EBook readers such as the Kindle will become ubiquitous, come down in price and serve the broadest content of written word. There’s still time for this to happen, Jake is not even two years old. But if I see him dragging his backpack full of books off the doorstep, on his way to school, I’ll give the Amish thing a try.

Current Kindle model: http://www.amazon.com/Kindle-Amazons-Wireless-Reading-Generation/dp/B00154JDAI

What "Done" means?

noreply@blogger.com (Anonymous) — Wed, 29 Oct 2008 16:49:00 +0000

Is it Done? This topic that is constantly reoccurring in the (agile) software development community.

Done is a magic keyword, with different meanings for different people.

For a business owner, Done means that the product is running and serving Customers
For a project manager, Done means that the code is implemented, tested in all testing cycles and delivered
For a development manager, Done means the code is implemented according to standard, commented, unit tested and deployed in testing environment
For a developer, Done often means that the tricky algorithms work, code compiles and was checked into Source Control. The HARD part is over and the code CAN run.

Here's a sample definition of Done for a Task (via scrumalliance) :

Coded/implemented
Peer reviewed (pair programming counts as peer review)
Code is run against current version in source control
Code is commented in source control and checked in
Code is commented on Public/Friend methods
Story/use case manual test plan updated
Unit tests written and passing
Build and package changes are communicated to build master
Task list hours are updated and task is closed out
All to-do items in code are completed

We need to establish a scale of Done, so that we can rate our "donnes" clearly, just like a good stake house does.
Oh, Sorry Sir, you didn't ask for a rare rib eye? My apologies, let me fix it for you! (The staff in a good stake house doesn't usually point out that the meat is properly cut, is very well seasoned and the last piece missing is a bit more heat. The stake is simply not done well).

In agile development, Team has a lot of sovereignty to make decisions and drive the implementation of Tasks. It takes an ownership of the Tasks and makes the implementation as good as can be.

But the Team also needs to clearly communicate the level of Done, as different stakeholders have different expectations. Only when the communication is clear, factual and correct the mutual trust can foster.

Let the Water fall

noreply@blogger.com (Anonymous) — Tue, 28 Oct 2008 19:41:00 +0000

On Waterfall software development methodology

Fig-1 Waterfall phases

So Waterfall is GREAT, right? It is GREAT for its risk mitigation ability, it is GREAT to produce bug free software and it is GREAT to produce mission critical software. It plays extremely well in regulatory environments. Above all, it is GREAT in maintaining of Status Quo in order to keep the aforementioned virtues of a system.

It runs Space Shuttles and it got us to the Moon.

Every phase is dependent on the completion of the previous phase; we do not code unless we have gathered requirements, analyzed it, and came up with design already. This gives Waterfall very SOLID structure, gives a big deal of comfort to organization that a project will be eventually completed, with all Ts crossed and Is dotted.

Auxiliary control mechanisms and directional layers and reporting structures are deployed alongside all of the phases, with very little overlap to boot. Testers do not have to care about development till the day they get the custody of the code that needs to be tested. Each phase is taken care of by a different group of people; roles and responsibilities are finely defined and distributed.
Each phase feeds into next one and one run through the mill and we are done. Unless...

The Waterfall is BAD, right? It's BAD because it is HEAVY, oh so SEQUENTIAL and downright stuck in the last century.

All the virtues of Waterfall come at a significant cost. Many people, often many organizations collaborate during Waterfall phases. Due to the great isolation of the Waterfall phases, communication becomes an overhead and bureaucracy prospers. Cost spirals, fat grows. Each of the phases is becoming longer, synergies are absent. Evolution of the product and keeping with the times are difficult - that's the price of a great Status Quo watchdog. We do get a bug free, mission critical software, though. Unless...

The most important and often overlooked aspect of Waterfall development sits right in front of our eyes. On the top of the pyramid. Basking in the sun. That's right, the REQUIREMENTS. It is the first coin we insert into the slot machine and it decides on the outcome. Crooked pennies do not need to apply. Weight of the coin needs to be precise, so does the width and diameter.

Waterfall assumes that requirements are exactly specified, are understood by all parties and do not change. Change the requirements and any of the phases will come to a screeching halt. Either you can restart the whole process or you take a shortcut and circumvent the rigid and fail proof process.
Most of the bugs in the system come from such shortcuts and firefights, negating the bug free property of the process. The system will retain the heavy cost associated with the process but will not be bug free and or fit of the mission critical label.

If you decide to do Waterfall, beware of change. And if there's a single change on a project it will probably be the REQUIREMENTS.

If there ever is a mission critical project with ZERO chance for requirements change, deep well of resources in a highly regulatory environment, I wouldn't hesitate subscribing to the Waterfall process. But I hear they are retiring the space shuttles ...