scribbles of the perennial debugger…
Posts tagged Architecture
Yeah sure!!!
Dec 28th
Since 2008 was my last year with my old employer, and to date, I have enjoyed new-found happiness with my new employer, I believe, one thing that has been bugging my mind for a long time now need to go away along with the closing days of 2008.
Back in the olden days, there was this person who I was trying to help. Who I was brainstorming with. Who’s endeavors I support. This person was so proud that he told me, “If you knew everything, why don’t you just take it!” He was referring to his team and to the product he is assigned to lead.
Well, Mr. nice guy, I haven’t forgotten that singlemost un-appreciative moment of egotistic and unprofessional whining. OK, here’s my turn to equate what this visionary-innovator-architect-leader has said to me.
If this guy was so good, how on earth functionality and performance was not managed well? Forget the “nebulous” requirements. There are always better ways to solve problems and requirements without getting too complex. Without sacrificing so much complexity, with proper management of change. IT resources would not have wanted to go away from this guy’s leadership. Technology transfer would have been managed well. I do not claim to be that good… but I do refute any bull this guy has ever said and done. I rebelled in my heart for such person being rewarded when more deserving ones are abound. There are people who through the years I have clashed with but I have tremendous respect for them for they stood for their own belief. And they really have something to strut, not just pretensions and sweet talks. I do not have anything against this person, personally. But given the choice, I don’t like to work with this person again.
Alright now, thank heavens I finally had the guts to yell this out… case closed.
of architectures and our CTO
Sep 16th
Last week was heck of week. All those weeks of preparation culminated with an audience with our CTO and his direct subordinate, the head the department responsible for delivering the unified framework we all should use (think of it, ala Spring, and even closer, ala AppFuse).
The outcome of the meeting was beyong expectations. It was more positive than we had expected. However, there are still corporate quircks to iron out, otherwise, everythin’s good.
I am a technical person, and contrary to my personal expecations, the conversation with our visitors were tuned to my dialect. It was not at all marketing and sales bull oriented. In the meeting, we were able to discuss strengths and weaknesses as per our respective approaches on how to build and what a framework should be. Yes, you might be guessing it right, our mother company has their own framework, our local business unit have its own. And why is that, you might ask. It’s because our former company used to be an independent company until it got acquired by my present company.
My life has been tuned to open source ever since I got “evangelized”. I know our architecture, and I don’t have any clue on how our competitors’ offerings are architected. With my decade-long stint, I can’t help but sulk it up to our weaknesses because I had only open source software to compare to. But this time, we (our biz unit and our mother company) mutually validated the strengths and goodness of the direction we are taking because our respective frameworks seem to be the same. However they’ve been born and evolved over different course of history, they seem to be the same. In this regard, I would resign to the fact that, yes, we did good in the architecture arena. And man, that feels good.
Though much fanfare and feel-good is seen from our respective frameworks, I still have reservations on how we have implemented some, if not most, components. I have to be honest, good architecture does not always equate to a good software or component-level design. Our functionality and architecture is strong. Some of our modules and components are not. If you wonder what they are and why I say it’s not ok, you can ask me personally.
All in all, the depression I gave been suffering from the company is alleviated. We have hope. All we need is decisiveness and of course, the budget to improve on our weaknesses. And when we do embark on improvement journey, I hope I’ll be there to lead that team.
Powered by ScribeFire.
My companions in heading home: a mini review (rant)
Oct 9th
HP iPAQ rw6828 PDA-Phone
My experience with this device has been productive ever since, sans the occasional and rare hangups (seems lesser than its architectural brethren, the O2 Atom). When I head home after office hours, I use this as my “iPod”. Yeah. It’s Windows Mobile 2005-based and it syncs with Windows Media Player. Well so far so good. My only complain is that the random-play does not seem to be random. I don’t know whether the device has its own list of favorites but it keeps on “randomly” repeating a group of songs over and over unless I manually hit the Next-track button.
Jabra BT620s Wireless Headphones
Technically, it’s good. I can use it for both listening to music (MP3s only as the FM receiver will only work on wired-mode) and for engaging in phone conversations. My complains are the following: (1) it’s heavy and large. It seemed to have been designed for an extra-large cranial circumference. (2) it does not have a “lock”. The functionalities are “nicely” hidden from behind the side panels. The only drawback is that it can easily be activated when accidentally pressed. Surely a not-so-nice battery eater when the headphones are in my bag.
Oh the temptations of technology…
The anti-pattern series: Exception-Handling
May 12th
With kudos to a good article at Java.net and to the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. We get a good eye-opener on the often-touted handle-your-exceptions-directive from your team lead or software architect. In the my previous posts, I have mentioned that anti-patterns should not be left unnoticed in the design and development time. I am starting this series of blog posts to collect and summarize an anti-pattern that I am sure, some stray developer out there in the world might be blissfully ignoring. So here goes the first: about exception handling. For more details, kindly refer to the java.net article or to the book.
Exception Handling Anti-patterns:
- Log and Throw – don’t log then throw. Do only one thing.
- Throwing Exception – a good programmer knows this is a _big_ no-no
- Throwing the Kitchen Sink - if not throwing Exception is good, you might as well don’t throw a big gamut of checked exceptions
- Catching Exception – again, while throwing Exception is a minus point, catching Exception is as evil as it is
- Destructive Wrapping – you will lose your valuable stack trace with this… for example throw new NewException(oldException.getMessage()). Got it?
- Log and Return Null – not always wrong, but it is more elegant to throw the checked exception instead of returning null
- Catch and Ignore – well almost everyone is guilty of this… suppression of exceptions!
- Throw from Within Finally – leave the finally alone. Be sure that your finally{} block will execute as peacefully and completely as it can
- Multi-Line Log Messages – this will eat up a lot of your log resource
- Unsupported Operation Returning Null – if you don’t have an implementation (yet), throw an unchecked UnsupportedOperationException instead of forcing the caller program to handle null
- Ignoring InterruptedException – for you thread maniacs, try to do something when you catch this exception. The InterruptedException is a clue that your thread should stop doing whatever it is doing. For more of this, go study thread programming.
- Relying on getCause() – and why rely? Rely on the actual thrown checked exception instead. Relying on the getCause() is a symptom of a bad design.
Here we go again… anti-patterns abound
Apr 28th
We are on the design phase again. Everyone, except my new team and perhaps the framework team, is doing design. I would commend some designers while I question (on a personal confidence note) some. And due to my years of stint manning the framework team, I have been consulted by my friends and traditional “internal clients” on how they should go about things that they intend to design… I would say some don’t come to me nor to anybody else to consult. Come on guys, what you churn out will not be perfect. At least, try to share your thoughts and see the problem upfront.
This is the finest and most fun time to correct some architectural and design mistakes we’ve been into. But nay, we’re still on it. A next round of design and development would have been a good time to rectify flaws even on its most minute amount. Good luck to everyone…
But wait! Design, design, design… endless tons of work… at snail pace iterations. And in the end, these designs will not be followed to the T. Why? Because of a flawed design. I am not saying that they are flawed from the beginning. What I mean is that these designs will miss something and would be tantamount to a redesign or development deliverable delay.
But wait, again… my general observations: anti-patterns are everywhere and there is a lack of attention to these. Hopefully, for the long duration of the design phase, at least a panel of experts try to identify the antipatterns while the application is being designed and not at the end when everyone is already wading through deep sh*t. A dedicated team of analysts should counter check the deliverables of designers and at the general design perspective. An advise to these people:
- Scrutinize a design and identify any problem (hope, you’ll be good at this… it’s like your QAing the product before it is even built)
- For problem cases, identify whether they establish a general trend (might be an antipattern)
- Redesign, as necessary
- Cascade the solutions to macro and micro levels to all other components (built on not yet built)
- Educate the designers
Like anything else in the universe, patterns and best practices have their negative counterparts. So stay aware of antipatterns.