CoolBeans

Add Simplicity

noreply@blogger.com (Daniel Maly) — 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 (Daniel Maly) — 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 component of software. Software Art is all about how do we translate an idea into instructions that computers understand, while losing as little of the original intent and scope as possible. Software Art is encompassing both What are we solving and How are we doing it, in exact measures of each. Software Art is the sweet science (doh!) of the Big Picture. It has some properties and mechanisms of its own, via which it impacts the results. The most important property of Software Art is SIMPLICITY.

To be continued ...

noreply@blogger.com (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 alphabetical order:

Android

Software Architecture

Best Practices

Software Design

Enterprise Portals

J2EE

Mainframes and NonStops

OOA and OOD

OSGi and all things modular

RIA

Services and SOA

Strategy and Planning

Browser as a Platform, HTML 5, WebSockets

noreply@blogger.com (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 (Daniel Maly) — 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 ...

Agile Values

noreply@blogger.com (Daniel Maly) — Tue, 28 Oct 2008 19:37:00 +0000

The four basic Agile values were described in Agile Manifesto in 2001. Brief interpretation of the values follows. I focused on the Working Software value, as it is the most relevant one to me at the moment.

1) Individuals and interactions over processes and tools
It's all about the TEAM which is executing the Tasks. Process and Tools exist in order to support the TEAM reaching its objectives.

2) Working software over comprehensive documentation
Test ALL THE TIME, deploy often and refactor constantly. Code by intention, not prescription. Design as you code and code as you design.

Coding by intention: What do I want to code? What is my intention? Coding starts with Interface as my understanding is vague and generic at first (I only know I need the code to do something and return something else), and evolves into concrete implementation as I learn and understand the topic better as-I-go. I also know basic test requirements from the beginning, so I can start testing as soon as I decided on my Interface.

Refactoring: Did I understand the requirement correctly and is it still reflected in my code? Is it as simple as can be? I rarely get my code spot on from the beginning, so refactoring is constant effort. And it's FUN! Only constant Refactoring creates Beautiful Code.

Detailed Design and documentation: Is often formalized at the end of the iterations cycle in extra iteration called a Landing Strip

3) Responding to change over following a plan
Plan is created and owned by the TEAM, is alive and constantly change after every iteration. If we get behind or ahead, we will know at the end of each ~10 days long Iteration.

4) Customer Collaboration over contract negotiation
The TEAM includes ALL the collaborating parties. On a typical application release we would have a BA and a PM in all of our daily stand-ups (and it would still take only 1/2hr!). Constant collaboration of all parties is more important than signing off "requirements" and delivering "something" few months later.

On poop.

noreply@blogger.com (Daniel Maly) — Mon, 03 Mar 2008 20:11:00 +0000

I'm an expert.

If there's ever a need to produce extraordinary amount of uncontainable poop, I'm the man to call.

Man for the job.

I shall not disappoint, won't let you down.

I challenge anybody to try and contain my product. It will scale mountains, cross rivers, conquer desserts.

It can't be done. My poop will roam free, as it was intended.

No diaper, article of clothing or furniture should dare to stand in its way.

Just try ... and weep. I'll smile with my toothless, angelic grin.

Resistance is futile.

Angel from poop heaven.

CoolBeans revealed

noreply@blogger.com (Daniel Maly) — Wed, 10 Aug 2005 17:26:00 +0000

So it seems that CoolBeans have revealed itself. CoolBeans is a concept of anything interesting (or cool) regarding beans. Bean is a very granular entity (literally) and can be pretty much anything. Since I'm involved in this software business my CoolBeans are mostly related to it.
So CoolBeans are about technology, software, gadgets and thoughts that tend to coolness.
Also, short quotations from the work of Raymond Lin (RL), my distinguished colleague whose words are sometimes more than truth.

http://wiki.bonsaitalk.com/index.php/Coolbeans

CoolBeans: XMLBeans, JAX-RPC and Serialization

noreply@blogger.com (Daniel Maly) — Wed, 10 Aug 2005 17:08:00 +0000

These three technologies (among others) have something in common. A feature that is easily overlooked, but still vital to smart computing.

Let’s define first:

Serialization: An act of writing objects onto a medium in a serial, byte-by-byte manner. In Java, any object that can do this has to at least implement mark-up interface java.io.Serializable. Any referenced objects have to be Serializable and will be serialized altogether.

JAX-RPC: Java API for XML-based RemoteProcedureCall. You may have sensed the tie-in to serialization via the RPC portion of the acronym, but that’s not the main reason it is here. Rather, we think of mapping of the Objects to SOAP (SimpleObjectAccessProtocol) messages for RPC call (webservice). We think of the mechanism we map Objects and primitive types into SOAP.

XMLBeans: Java-XML binding tool. The XML schema is converted into set of Java classes representing elements. Inheritance and Composition is used to reflect nested elements and document structure. XML nodes can be manipulated via accessors and mutators of particular java object.

The common feature is the ability to create an object tree that decomposes any Object into its smaller and smaller denominators. Serializable object is serializable only when all the nested and referenced objects are serializable too. All building blocks of an object will be serialized one by one, thus creating basic object tree. JAX-RPC also creates SOAP elements by decomposition mechanism and XMLBeans go even further by naming it right. Generally, the basic building block is an object with certain properties (preferably primitive) and accessors and mutators. A JavaBean.

JavaBeans are very powerful concept because of its decomposition capabilities and the ability to shift our focus from the complexities of a system towards the real nature and desired functionality of the system. In Fit testing (testing of business requirements before any code is written), anything is a JavaBean to begin with, be it a Host System, Java Object or database. This fine decomposition gives us very interesting and important view at the overall system, uncluttered of the “complexities”.

This also enforces the rule that healthy object has properties and responsibilities that belong only to this object; otherwise decomposition into simple object tree is not possible. That’s how we get to the very basics again.

http://java.sun.com/docs/books/tutorial/essential/io/serialization.html

http://dev2dev.bea.com/xml/xmlbeans.csp

http://java.sun.com/xml/jaxrpc/index.jsp

Fair comparison

noreply@blogger.com (Daniel Maly) — Wed, 10 Aug 2005 13:31:00 +0000

YES! But if you do not consider the differences, they are the same!

RL Aug 10 05

Damn you Random!

noreply@blogger.com (Daniel Maly) — Wed, 03 Aug 2005 13:29:00 +0000

Hmmm ... yes, ... it will be more clear once we remove the random function...

RL Aug 02 05