Site Sponsors:
UML: Getting Started 
I've no idea why so many software developers seem to be afraid of creating & sharing diagrams. --Not only is a picture worth 1,000 words, but when we work with others to chart-out the things we need to do, a set of diagrams will often save a similar number of defect, meeting, & R&D hours.

Of course diagramming common knowledge is often a guaranteed time waster, as well! --But when requirements are vague and / or the tasks are complex, then knowing how to depict systems in an industry-standard manner should be of obvious value?

So please allow me to share our free training on the Unified Modelling Language (UML). By way of a bonus, the video series includes an example of an Open Source Project designed by using a very few UML artifacts to both capture & describe project operations.

[ add comment ] ( 423 views )   |  permalink  |  related link
Waterfall & Agile - Can't We All Just Get Along? 

Big Need

Working with the Pentagon, one discovers that planning works like any other big business. There is a very real need to let people who are giving you lots of dollars know what they are going to get for their money.

Indeed, from DoDAF to UML, the designs we generate - as well as the software re-use we plan - often needs to be pretty specific. -Not only are lives at risk, but in a time when national defense is rapidly loosing funding to "social progress," the Waterfall approach is increasingly important. Why? Because every dollar counts. More than one organization can be involved. Meticulous planning is required.

Old Patterns

In general, many have discovered that - the bigger the undertaking, the larger the need for comprehensive planning - sometimes down to a demonstrative code-level / integration test plan.

Conversely, when it comes to our prototypical, polar, or recursive development activities (modernly known as "Agile") the need to take a sprint down the requirements de-jure, manage our burn-down-lists, test, and even continuously integrate, are time-proven ways to keep both system & software teams accountable.

Unfortunately, many folks do not know how old "Agile" techniques truly are! Rather than understanding that Waterfall and Agile have always worked together, I often discover people saying odd things such as "we are an agile", or "we are a waterfall" company?

Indeed, when someone is handing you a check for hundreds of thousands - or millions - of dollars, rather than expecting the "trust me, we are agile" mantra, or “waterfall will get us there,” it is not beyond the realm of realistic exception to have someone say "that is not enough."

Strategy & Tactics

Of course, software development is all about patterns. When it comes to the unnecessary camps between Waterfall & Agile, I therefore like to tell developers that – for any large undertaking – there are usually two (2) different plans: The Strategic, and the Tactical.

Sound like warfare? Perhaps. But strategic and tactical planning patterns are found in several other places, as well.

For example, in large-scale, modern business, the need for the “where are we going” over the “what are you doing” techniques often find their expression in an “Enterprise Architecture”, and the ever-present “Implementation Architecture?” While the delineation between the two needs might indeed seem a little loose at the moment, such is the way of a work-in-progress abstraction.

Nevertheless, in highly visible, large undertakings I propose that Waterfall is the strategic, while Agile – the tactical? Why? Because not only can BOTH Agile & Waterfall be rightly required, but for decades they BOTH have worked together just fine.

New Idea?

In warfare, knowing where we are going, as well as how we are getting there, are important. Considering each is why both strategic & tactical planning are important. Waterfall planing, Agile execution.

In software, and from time to time, surely both Waterfall & Agile should be found co-existing. Certainly whenever huge amounts of resources are to be expended. Individually, both undertakings just make sense. Together, both Agile & Waterfall can help us work miracles. Just like in battle.

Heads & Tails

Whenever both Agile & Waterfall approaches are working well together, we can certainly see the strategic, as well as the tactical aspects-in-motion. Yet, because the concept of creating a synergistic cooperation between Agile & Waterfall is unique to many, perhaps a new term is required?

So I was thinking (a dangerous pastime, I know!) -In as much as the collaboration between the strategic & tactical dates back thru a millennia of combat, rather than soft-warfare, perhaps a new moniker is required. Whenever tactics and strategies begin to complement one another a tad more classically than they presently might, then perhaps we should call it waging 'warefare, instead?

Enjoy the Journey!


[ add comment ] ( 1895 views )   |  permalink
Dot-Bomb Developer Woes? 
Those of us who have been writing software for any length of time are becoming distressed by the army of - what seems to be increasingly - blissfully ignorant, if not implicitly arrogant - software maintainers.

Harsh Words?

Indeed, from completely alienating decade-long users from even wanting to touch things like the new Microsoft Word (ignorant - ever heard of Microsoft’s CUA guidelines?), to completely breaking our code & understanding of how a framework works (arrogant - do they think that the folks who originally designed it were stupid?), the prognosis for an egalitarian future looks about as short as the tenure that accompanies many of our maintenance woes.


Such were my thoughts as I set my hand toward updating my electronic book reader recently. Wanting to simply replace a JTextArea in favour of some owner-drawn text, we blissfully set about creating our own JPanel to do just that.

Sadly, as I tested my new JPanel, "OMG" was the polite version of what raced thru my mind. The Panel drew. Then it blanked & went fascinatingly stupid on me.

What could be the problem?

Dues, & Dues Not?

Of course, for those of us who have paid our dues in learning the way of the paint(), validate() and update() paradigm, the recommended way of doing things TODAY in Java is to instead use paintComponent(). No problems there. Lots of folks have blogged about it: The default super.paint() quite reasonably manages the draw, as well as paintChildren(etc). Nice design.


The problem is that, even after replacing paint() with paintComponent(), that the flippin' thing still blanks... and blanks... and draws & blanks. --So much so that folks who encounter the problem are being humiliated by folks who thought they knew how painting in Java works.

The Source is Strong with Us

Not to worry though, while only about .01% of the blogs are keeping up with the latest (or even dare date their articles!) Java lets us get to the source of the problem. By chasing the implementation down to the new PaintManager, it became obvious that double-buffering was the culprit. (Image was grabbed before my render - Blank!)

Know Thy Google...

Now that I knew what to 'google for, we came across a nice little post or two on the subject. Push comes to shove, it seems that most folks are okay with the fact that RepaintManager will work so as to ignore any traditional way of using a canvas, paint() or paintComponent() call. I, as well as many others, are not. Blanking our content by default is not cool. It is arrogant.


Sure, the point was made on posts cerca & since 2008 that "the comment on the paint manager has a warning", but the effect is to enforce behaviour on folks who might want to move their legacies forward without reading up on every framework & feature change. In short, things did not blank by default.

Who cares about that GrayRect fix for JDK 6 ... We assume that a company is using tenured resources. (Tenured software develops know their legacies.) We presume that companies know that the best software developer are SMEs on their products well before they are allowed to write a line of code.

Ass u me

I suppose we are now learning never to assume: In the battle between cost, quality, and time, quality takes a back seat. That has ever been the case?

Yet because anyone with a compiler-in-hand is allowed to "save" their companies a few dollars for-the-year, companies should not, therefore, mind as folks decide to abandon their flagship projects. Products like Mic.sos.oft Office. --Look at the savings hiring cheap developers brings!

But Frameworks like Swing impact millions of products. The way it operates should be sacred. Indeed, as I turn a jaundiced eye toward Java ballyhooing their embedded prowess this month, anyone with any tenure simply laughs up their sleeves. Why? Because we know that things like Hadoop are insanely busy re-writing the PERFORMANCE CRITICAL PARTS of their ENTERPRISE Map/Reduce TOOLING in C/C++. (Smile: Only those tiny players - like Facebook, Google, Yahoo, and the DoD, use Hadoop. There are only so many rooms full of servers one should be willing to host: Little wonder they have the need for speed!) (Amazon loves C/C++)

One Map / Reduce Process per JVM = lots of wasted processing power. Indeed, like everyone else, I have my OWN inane theory on one origin of black holes: I believe that, whenever the amount of idle oscillating processing power exceeds the ambient life-force energy (or something :) in any given solar system, that an inevitable implosion results when any rogue dark, strange, uncle (or aunty) -matter migrates there-to. --So the next time you ponder the Horsehead Nebula (or perhaps a stray asteroid ever-drifting nearer our orb?), whimsically imagine a logo in the midst of each perplexity, all body-snatchingly hissing & pointing our way, effectively declaring "Java / Intel Inside"? ;-)

The Way of the Farce

Java Everywhere, indeed? -You want to put Java in a pacemaker with 4K memory? Wow!

Anyone out there understand the very language an operating system is written in (C/C++) ... and why? BECAUSE C/C++ IS FASTER THAN JAVA, FOLKS! That, after all, is WHY we have JNI!

But does anyone c-a-r-e?

Of course not. It is all about marketing today - let the developer & user hang.

For shame!

O, say ... can you .. C?

But when it comes time for ME to look into OUR set-top box, operating system, interstellar probe, weapons system, or pacemaker (!), I, like every other tenured software developer, wants to see a sticker that effectively says "C/C++ Inside."

In the embedded marketplace, all we have to do is to witness how quickly innovations like the BASIC STAMP platform lost their market to AVR / Arduino (even Radio Shack now carries Arduino!) to see how much better C/C++ is ... ! Would anyone even laughingly consider writing an operating system in 100% pure Java?

So call me prejudiced. Call me evil. Call me a communist, liberal, or democrat... but we must believe that part of being a professional is to know the right tool, for the right job.

Conversely, part of being a neophyte is to do well to (1) learn how to use a hammer, but then to do poorly & try to (2) turn everything into a nail. That is just being lazy. (i.e. Be careful who you call "D-e-m-o-c-r-a-t"?! ;-)


Okay - I got that our of my system (pun intended?) Everyone knows I love Java. I also love the way Obama was allowed to destroy the financial future of our nation. I also cherish the fact that both Oracle & Obama still think that what they have done is right. (I voted for the other guy :) Smart is what smart does?

So while far from being the most efficient implementation, and completely for educational purposes, here is how I solved the blinking text (or anything else you might want to draw!) problem in Java:

public void paintComponent(Graphics gr) {
if (manager == null) {
manager = RepaintManager.currentManager(this);

Now it works the way it did before all of those wonderful developers at Sun (ahem) forced their RepaintManager on U.S.



[ add comment ] ( 2864 views )   |  permalink  |  related link

| 1 | 2 | Next> Last>>