Prototype

Name : Prototype

Context : Obtain a copy

Consequences :

1)Add remove products at runtime
2)Specify new objects by varying value or structure
3)Reduced Subclassing

4)Configure an application with class dynamically

Examples

Anything implementing clone(),

Class

Factory method

Name : Factory Method
Context : Hide the implementation class but defer the instantiation to subclass

Consequence
a) Provides hooks for subclass

Examples

Calendar.getInstance()

Connection conn = java.sql.DriverManager.getConnection(uri, name, password);

Abstract Factory

Name : Abstract Factory
Context : Creating Related family of objects
Example: Toolkit(awt)

java.sql.Connection (sort of creates Statements and PreparedStatements and CallableStatements where each is specific to the database)
Consequence
1) Exchange Product Families
2) Supporting new kinds of products
3) Factories are normally singletons! But they need not be.

4)Note that every factory must support every type of object to be created. This is sometimes problematic.

Singleton (Creational)

Name : Singleton
Comment : Probably the best known (atleast if you go by answers you get in interviews to the question 'Patterns you have used') of the design patterns and probably one of the text book cases of people ignoring understand the context and understand the consequences when it comes to this pattern
Context : Need only 1(or a fixed or controllable number of instances) (e.g. memory consumption , or heavy initialization like reading a file,a requirement - there is only one Neo, a pre java 1.5 enum such that == can be used )
Examples : Single Instance (java.awt.Toolkit, Inspector)
Consequences :
a) Controlled access to state
b) Permits a variable number of instances (e.g. access to any object pool)!
c) Watch out for real world multiple managed servers, clusters etc(older versions of Expresso framework used an in memory primary key generator as an incremented singleton - no use in a cluster. Real world naive code that uses a timestamp plus ip address as unique key through a singleton)
d) Watch out for synchronized access for loading the singleton, thread safety, shared state.
e) Watch out for serializable (might break singletoness if you dont follow effective java)
f) Watch out for static block errors during initialization(if initialising eagerly). Will cause NoClassDefFoundErrors.
g) Watch out for being unable to reset a singleton (e.g. a singleton that reads a file and stores it.If your not careful , changing the file needs a bounce of the server)
h) Watch out for singletonitis. i.e. Making classes singleton even when there is no shared state, no performance or initialisation penalty.
i) Watch out for problems testing the singleton

With all the Watch out's is this pattern worth the trouble? read the context!

Design Patterns Course

The following series of posts deal with a design pattern course I conducted for a few colleagues of my team who insisted that I knew enough to conduct such a course(I don't). One of the problems I had faced while attending the design patterns course conducted by probably the best Technical Manager I've worked under (Homi Bharda) was that practical examples were hard to come by, where you could see the usefullness and though the Design patterns book by Erich Gamma did point to some examples they almost always dealt with GUI heavy , stateful , highly object oriented programs while at that stage I dealt with mostly stateless CRUD web based applications.
I resolved that any course I took would show practical examples and what better example than the Java API which was quite familiar to my colleagues. I also had a lot of problem differentiating between patterns. Some of the Factory patterns looked alike. Some of the patterns like Command and Strategy looked alike. I resolved to have some comparisons at least.

What these notes dont have is my bitterly cynical comments e.g. of people who code such that all their classes have a suffix which is pattern e.g. ObjectCommand uses an ObjectFacade uses an ObjectFactory creates an ObjectService which uses an ObjectDAO and returns an ObjectAdapter which wraps an ObjectDecorator which wraps a ObjectDTO (Disclaimer I have done this too). This literally is the developer's cry look Im a designer , I use patterns , I even know their names! But ask them Give me some examples of design patterns in the Java SDK and we have a) Blank Stares b) Singleton c) A very very few Decorator.
So anyway other than the above rant , very few cynical comments


General Notes
What is a pattern ?
A Name, A Recurring problem with context, A recommended Solution(or way ahead), Consequences and Alternatives
The bit a lot of people miss out is the Context and the Consequence. A pattern cannot be used irrespective of the context . This causes problems like 'Singletonitis'. A pattern always has some consequence. A pattern probably does have alternatives which are to be evaluated.
A pattern need not always be up front design, you can arrive at many patterns with a judicious use of refactoring and some simple principles notably DRY.
Patterns are also sometimes subsumed by the language or the platform (e.g. Factory in Visual Basic COM and Iterator in java) and some people refer to patterns as deficiency in the language / platform ( I dont agree!).
Anyone who does anything with Design Patterns has to refer to Erich Gamma's et al book , and thats what I have based this on including the organisation of the patterns as Creational, Behavioral and Structural. Its quite difficult for novices (like me) to differentiate what between what constitutes a behavioral or structural pattern so dont bother right now.
Also note that any Object oriented system has available to it the mechanisms of Polymorphism and Inheritance (Implementation of Interface). Therefore all diagrams of Design patterns will look similar in a lot of case. it is necessary to understand the nuance and differences and context.
And lastly in a web project , differentiate between building a framework and solving a problem at hand. Its very easy to get carried away and over engineer and its as easy to under engineer, and it's also simple to shout TDD, refactoring , agile. Ultimately experience is what you use to decide whether you need a pattern upfront or later, Refactor or not. And anyone who tells you otherwise is either a manager or a consultant.

Testing

You really appreciate the value of tests (especially regression) when you have to fix some code which is complex and is used in multiple places and you aren't sure of the various conditions under which it gets invoked (or even what the result should be). Unfortunately it is sometimes difficult to convince management. We asked and were denied initially anyway , for a separate environment to create and run tests. The separate environments were needed because of the extreme complexity of the business needed, in my opinion, an environment where the initial state is exactly known , otherwise there is no way to accurately predict the outcome of running time sensitive, old data sensitive scenarios. However the cost of maintaing said environment was deemed to be too high. Im not so sure. anyway we are getting an environment so yay, let the games begin.
It's also at time like these that you realise , how out of touch with reality , the TDD/Agile/ JUnit testing people that you see are , because they never seem to discuss anything but unit testing.
I cant see unit test's adding much value to the system I work in , but oh what wouldn't I give for a set of repeatable integration and functional tests.
Other than the really good Java Next Generation Testing book I havent seen the Testing books deal with real world stuff. (Did anyone else think that the Junit cookbook example of Money was representative of what people test in an automated way in real life)

So here are the things that make the testing complicated
a. The system run's on a cluster. Problems have been reported on the cluster , some of which have found to be environment related and some are code related. Would anything other than in container testing on representative environments find this out?. This deals directly with the people advocating 'mocking' interfaces, not running in container, having fast running tests etc.
b. One of the defects was caused when two unrelated processes ran at exactly the same time and on the same server of the cluster. The processes shared infrastructure code but were business wise and code wise unrelated. How would a test have found this out , other than sheer luck? Note that junit as a framework is really bad. Again this is not a complaint about JUnit, just that you dont see people discussing concurrent testing of unrelated data.
c. A complex Architecture. A portal sends data asynchronously (JMS) to a WLI system which has multiple processes , which in turn needs a lot of system data (histories) to perform calculations, makes its business decisions using a set of business rules which are User Configurable(using a totally different system) and then persists this data to a database.
Assuming you want to test that everything works end to end, is there any other way other than restoring the system to a known point in time(so you know what the out come should be?). The catch again is that running the same test on the exact same data might not still return the same results because the results are time sensitive (e.g. there is a different contract for 2007 as compared to 2008 so running the test in 2008 will give you different results).
d. The results depend on the sequence of tests. This isn't a code problem , this is exactly how the business works. Other than creating different data for different cases , this is difficult to solve. In addition you do want to also test what happens when a particular sequence of events occur ( a claim is in , it is paid, the cheque is sent, the claim is adjusted, a new check is sent , the first one is returned, now assert). How is it that the unit testing folks shout themselves hoarse that tests should be independent of each other. I know I know , what I have described isn't a unit test. But you see , the individual bits work. The sequence fails.
Oh I can go on. But there is an India v/s Australia cricket match. Go India!

Debugging

Due to circumstances beyond our control , we've had to take up fixing someone else's code. The business rules are complex (which means the code must be so). There are no existing tests (this is a consequence of both the complex rules and a complex architecture , the latter could be simplified if it were not for the fact that the project is years late). Now the TDD guys are probably jumping up and down at this stage , pointing out that the lack of tests is the reason why everything is so complex , just ignore them , we'll get to these folks later. The bottom line is there are no tests, we are trying to create some regression tests, that will take time , meanwhile there are still bugs to be resolved. I was assigned one of them.
It took me 2 hours to setup the environment . Ones a weblogic portal domain and Ones a weblogic integration domain. The build for the portal takes about 30 minutes after which weblogic workshop duly crashes. I have to point my servers to a configuration other than their default which needs me to mess around manually. It takes another hour to understand what the defect is. it takes some more time to verify that the tester is indeed right, the system is doing something wrong. It takes some time to identify the areas of code that are possibly the cause. it takes a couple of hours to understand the nuances in the mostly undocumented code.
I then have to go and ask another dev, whether the testers expected results are correct, and it turns out they aren't. There is a defect and what the system currently does is wrong , but what should the system do is undocumented and unknown. We could make a guess but this impacts other systems so we need them to confirm. A meeting is scheduled.
The meeting lasts 2 hours. Some issues are resolved, Some new ones are raised. Some have to be followed up with other people. Armed with some more knowledge I look through the code. I get a sudden inspiration, I test out two scenarios , it looks like I'm right.

The defect is fixed by modifying all of two lines of code. Total time to fix defect ? 1.5 days.

Useful links

Advanced Pageflow
CM API usage example
Faults and Contingencies
WLST offline

Weblogic Portal interview questions

The following are the Portal interview questions that ive used or kept or have been asked(in no particular order , and no answers either :) )
I do not include questions (e.g. what is a nested pageflow) that can be answered with google.
Also see Weblogic Portal interview questions - II

• In what situations can you not use a UUP ?. What factors determine choosing a UUP?
• What are the different techniques you can use for Inter Portlet Communications?. What are the pros and cons of each technique?.
• Would you choose 1 desktop with entitlements or multiple desktops? Why?
• What are the options for security in Weblogic Portal?
• Can you change a LookAndFeel at runtime ?, if so what are the alternatives?
• What is the impact of using AJAX in a portlet (out of the box or otherwise)?
• Why should pageflow variables be serializable?
• If your using a file repository for content and you have a webserver in front of the application servers who serves the static files?
• When do you use the refresh action?
• What happens if the validate method of your form bean throws an exception
• How do you use the struts validation framework with BEA pageflows?
• The BEA pageflow documentation mentions that there is only 1 current pageflow. And that the current pageflow is destroyed when a new one is accessed. is that accurate?
• What all features should a screen scraping portlet possess?

To be continued...

Weblogic debug flags

Reproduced from Hussein Badakhchani's Blog and comments
weblogic debug flags(8.1)
IIOP
weblogic.iiop.ots
weblogic.iiop.transport
weblogic.iiop.marshal
weblogic.iiop.startup

JDBC/Data Sources
weblogic.JDBCConn
weblogic.JDBCSQL
weblogic.JDBCConnStackTrace

JMX/Deployment
weblogic.commoAdmin
weblogic.commoProxy
weblogic.deployerRuntime
weblogic.MasterDeployer
weblogic.deployTask
weblogic.deployHelper
weblogic.MasterDeployer
weblogic.OamDelta
weblogic.OamVersion
weblogic.slaveDeployer.semaphore
weblogic.slaveDeployer
weblogic.ConfigMBean
weblogic.ConfigMBeanEncrypt
weblogic.ConfigMBeanSetAttribute
weblogic.management.DynamicMBeanImpl
weblogic.management.DynamicMBeanImpl.setget
weblogic.mbeanProxyCache
weblogic.mbeanDelete
weblogic.mbeanQuery
weblogic.MBeanInteropList
weblogic.mbeanProxy
weblogic.registerMBean
weblogic.getMBeanInfo
weblogic.getMBeanAttributes
weblogic.addDependenciesRecursively
weblogic.MBeanListener
weblogic.application
weblogic.deployer
weblogic.appPoller
weblogic.appManager
weblogic.BootstrapServlet
weblogic.fileDistributionServlet

Application Deployment
weblogic.J2EEApplication
weblogic.application
weblogic.appPoller
weblogic.appManager

JTA
weblogic.JTAGateway
weblogic.JTAGatewayStackTrace
weblogic.JTA2PC
weblogic.JTA2PCStackTrace
weblogic.JTAHealth
weblogic.JTAPropagate
weblogic.JTARecovery
weblogic.JTAXA
weblogic.JTAXAStackTrace
weblogic.JTAResourceHealth
weblogic.JTAMigration
weblogic.JTARecoveryStackTrace
weblogic.JTANaming
weblogic.JTATLOG
weblogic.JTALifecycle

EJB
weblogic.ejb.cache.debug
weblogic.ejb.cache.verbose
ejb.enableCacheDump
weblogic.ejb20.cmp.rdbms.debug
weblogic.ejb20.cmp.rdbms.verbose
weblogic.ejb20.persistence.debug
weblogic.ejb20.persistence.verbose
weblogic.ejb20.compliance.debug
weblogic.ejb20.compliance.verbose
weblogic.ejb.deployment.debug
weblogic.ejb.deployment.verbose
weblogic.ejb20.dd.xml
weblogic.ejb.deployer.debug
weblogic.ejb.deployer.verbose
weblogic.ejb.verbose.deployment
weblogic.ejb20.ejbc.debug
weblogic.ejb20.ejbc.verbose
weblogic.ejb.runtime.debug
weblogic.ejb.runtime.verbose
weblogic.ejb20.jms.poll.debug
weblogic.ejb20.jms.poll.verbose
weblogic.ejb20.security.debug
weblogic.ejb20.security.verbose
weblogic.ejb.locks.debug
weblogic.ejb.locks.verbose
weblogic.ejb.bean.manager.debug
weblogic.ejb.bean.manager.verbose
weblogic.ejb.pool.InstancePool.debug
weblogic.ejb.pool.InstancePool.verbose
weblogic.ejb.swap.debug
weblogic.ejb.swap.verbose
weblogic.j2ee.dd.xml

General
weblogic.debug
weblogic.kernel.debug
weblogic.debug.DebugConnection
weblogic.debug.DebugRouting
weblogic.debug.DebugMessaging
weblogic.debug.isLogRemoteExceptionsEnabled
weblogic.StdoutDebugEnabled

WLI
wlc.debug.signature
wli.bpm.client.security.debug
wli.bpm.studio.timeprocessor.debug
wli.bpm.studio.debug
wli.bpm.server.common.timedevent.debug
wli.bpm.server.common.xmltemplate.debug
wli.bpm.server.eventprocessor.addrmsgdebug
wli.bpm.server.eventprocessor.debug
wli.bpm.server.jms.debug
wli.bpm.server.plugin.debug
wli.bpm.server.workflow.debug
wli.bpm.server.businesscalendar.debug
wli.bpm.server.busop.debug
wli.bpm.server.workflow.action.taskduedate.debug
wli.bpm.server.workflow.timedevent.debug
wli.bpm.server.xml.debug
wli.bpm.server.xslt.debug
wli.bpm.server.workflow.start.debug
wli.bpm.server.workflowprocessor.debug
wli.common.server.errorlistener.debug

Messaging Bridge
-Dweblogic.debug.DebugMessagingBridgeStartup=true -Dweblogic.debug.DebugMessagingBridgeRuntime=true And two others for stdout and stderr : -Dweblogic.Stdout= -Dweblogic.Stderr=

SSL
-Dweblogic.security.SSL.verbose=true -Dssl.debug=true

-9.x available via console plus
webservices: -Dweblogic.wsee.verbose=*

6.x,7.x
http://wldj.sys-con.com/read/42733.htm

RMI debug flags
java.rmi.server.logCalls=true
sun.rmi.loader.logLevel=[BRIEF|VERBOSE]
sun.rmi.server.exceptionTrace
sun.rmi.server.logLevel=[BRIEF|VERBOSE]

More straws

http://jeffsutherland.com/scrum/2006/11/scrum-supports-cmmi-level-5.html
http://jeffsutherland.com/scrum/2006/11/is-cmmi-worth-doing.html
From the inventor of scrum
(Disclaimer i am working in a CMM Level 5 company and its possible indeed probable i am biased)
So the agile management folks see value in CMM level 5 principles. After all what could be incorrect about
Level 1 - Uncertainty. Success depends on individual effort.
Level 2 - Awakening. Basic project management practices are established.
Level 3 - Enlightenment. Standard process throughout organization.
Level 4 - Wisdom. Detailed metrics are collected and evaluated.
Level 5 - Certainty. Continuous process improvement via metrics feedback.
Wouldnt everyone want to be level 5 , certain their project succeeds?
But isnt agile about people above process?
Doesnt agile tacitly imply that if the people arent good no process is going to save anything?
Certainly there isnt anything in agile that forbids collection of metrics and forbids improvement. Indeed doesnt the automation of everything in sight actually allow you to do this.
But but but and herein lies the problem, the practice of collecting metrics is so perverted (see the timesheets which have a task called filling in timesheet) that almost always means that people will fudge it.
It also looks like agile management consultants have discovered there is money to be made by coaching people to be agile scrum cmmi pcmm bs577 compliant. Or whatever.
So will the agilisits be enlightened? Does a standard process have more value than a tweaked one? Whatever happened to the these are guidelines and must be changed for your project, use whatever works for you?

Agile no more

Its amazing to see how developer friendly practices are perverted into management friendly practices as soon as a pack of managers are let loose on them.Right so lets begin at the beginning Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan (http://www.agilemanifesto.org)While we could quible over whether we collaborate with customers or negotiate with them , its fairly reasonable to assume that no software engineer is going to disagree with the spirit of what was said here.All of the above principles are developer friendly. No more follow that CMM level 5 process, No more according to my project plan we should have finished 53.23% percent of project. are we there yet?But look agile has crossed the chasm and what do we haveAgile consultants who have the "you must tailor agile to meet your needs" that means you need an agile coach or a scrum master whatnot because evidently if you tried to do it yourself your project would fail because you would do agile wrong.Oh look agile projects do need management. And it must be something new otherwise how would we consultants ever earn money?Heres a new management technique. Lets call it Scrum. We cant obviously have a position called Project Manager , lets call it scrum master. Lets not call it a requirements document, lets call it a product backlog. Lets not call it an iteration , lets call it a sprint. Oh yes how about burndown charts, yep sounds like something people would pay money to be taught what it is. Oh and wait we need to know what our teammates are upto every minute. Lets ask for status updates every day. Oh and we need to have data on the minutest of things. Hmm we cant call it a timesheet but we'll make them fill up the hours for every minute task and we'll make them constantly reestimate each task.Ok so thats an exaggeration.But think about it. Say the functionality on a website was show orders for a user. What would a developer say (lets assume the overall architecture and software and platforms have been decided). Mostly something like ok it would take about a week for me to do it. If you fell behind you 'd sit up for 2 hours more if you were ahead you'd quit and go home early. In about a week you'd be done if you were reasonably competent. Developer friendly? Id think so. if there were problem you'd escalate as soon as you knew of it. If the problem was technical you'd ask your peers at lunch or tea.But thats not what's being practised.1 week as a coarse estimate wont do any more. You have to provide finer tasks so that you know if you are in red. You have to track at an hour basis for the tasks. You have to give an update every day. You have to work uniformly for 8 hours every day because supposedly that increases productivity. Bah. Anyone who's coded knows that if the problem is interesting and you've started on it , you wont stop unless you've solved the problem Or atleast its that way for some people.Not all people are alike.And so we come to the original manifesto. For the agile projectsIs it individual and interactions over processes and tools ? Probably not. look around the debates in agile . To pair program or not to (process) , to TDD or not to (process), unit test all code (process), daily standup calls(process), use wiki for collaboration (tool), use junit(tool) etc etc
Working software over comprehensive documentation ? Product/Sprint Backlogs, Burn down charts, User stories (all documentation)
Customer collaboration over contract negotiation ? Ambiguous at best. And certainly i have yet to see any agile consultants who havent negotiated contracts.
Responding to change over following a plan? No more and no less than before, perhaps evidenced by the fact that the manifesto is signed in 2001 and 5 years hence there has been no change to it. Lessons learnt in the 5 years have definitely not caused the manifesto to change. Rather any failures are met with the standard "you arent doing it right"
Perhaps the problem is in the first item in the process. Individuals. And individuals are flawed and biased.

More Agile

Burst out laughing when I read
“Soon all of our singletons were composite, we could use the factory method on our abstract factory to get the prototype of the builder which would make a proxy for the decorated adapter that acted as a facade for the visitor which took us to see all of our singletons”- http://jroller.com/page/rolsen?entry=turn_it_up_to_11
Since it reminds me of a certain project I was in where the chief designers had obviously come out of a design patterns course and so there were *Factory aplenty which then lead to the creation of a class named FactoryFactory and the clients of this API who ofcourse had their own factory came up with FactoryFactoryFactory. Ok the last class is fictional , but the one before that is an actual class.
And so yes the latest rage is Agile and Scrums and what nots. I remember reading Kent Beck’s book on extreme programming about 5 years ago when agile had not yet caught up here in India, agreeing vehemently on the accept change and disagreeing just as vehemently on pair programming (some people interpret this as side by side programming, a practice I wholeheartedly endorse , and not just for technical reasons, its how I met my wife to be :-) )
As the years went by and I saw more and more of the strict waterfall model , the im not going to start design till requirements are signed of, im not going to start development till design is signed off, I realized the agilest were right , waterfall like practices are no way to run a project. Agile was the way to go. And though we didn’t practice all the various XP practices or Scrum or whatever, most projects I worked on were pretty much flexible, with changes being accepted after the date for code freeze (which magically thawed)
Oh just to clarify , we are a service/project oriented organization , providing services to various clients. The client I work with now has decided to go Agile in a major way and to impress the client agile training is now mandatory for everyone in our group in our organization. And ive kept up with some of the articles that the agilists keep publishing. And so the inevitable conclusion. There is no practice in the world that people cant screw up.
So lets see where do we start.
First the proponents of agile itself. While they make the right noises (Each process must be tailored to what works for you), the answers given most of the time is ,(to quote cedric beust) “if you aren’t getting benefits from agile , you aren’t doing it right.”
Second the insistence by some on absolutely silly practices. Like Code the test first before you write the code. I cant and don’t want to code tests that don’t bloody well compile , I have to define the interfaces and classes implementing those first atleast! Though of course testing is good , automated tests are better, unit tests are ok, mock tests are ok, Integration tests are worth their value in gold. But try getting some agilist to talk about tests other than unit tests.
Then we have the silly rules that follow from the above. You must have 90% coverage in your tests cases, otherwise code is rejected. Heres a thought experiment. Write a function doubleIt , return the value 4 always and write a test case which passes in the value 2. You have voila 100% coverage. Beat that. No need to write more tests. If you impose silly rules , developers will work around them.
And then we have the other problems. Daily status calls, not exceeding 15 mins. Must be at the start of the day. Ok cool. Umm the delivery head is US based, the customer in UK and the dev team in India. Whats the start of the day? Oh agile doesn’t work so well for distributed teams! Well what do I do then go back to waterfall? Stupid.
And the ofcourse the famous if you aren’t doing practice x, you aren’t agile.
I think I prefer the time when in a project of duration of 1 month you could relax for 15 days and then work double for the next 15 instead of work uniformly for the 30 days.
Though people may say that quality in the latter case is better, I don’t think that’s necessary.
I don’t think agile works in the real world. Distributed teams are a fact of life. Multi vendor projects with conflicting interests are a fact of life too. I suppose agile would work with a closely knit team. But that’s fast becoming an exception in the areas we work.
And with new processes and positions (like agile coach) the Agile methodology is becoming as rigid as the other processes.
And a final thought whats remained the rule in software , good people can make any process work, incompetents can make any process fail.

Agile

The other day I got a ppt from a friend who got it from someone else about a project in my company which is a “success” because how they implemented “agile methodologies” and how it helped and the practices they followed with general patting of backs and lessons learnt and improvements still to be made.
It’s a 75 slide power point.
Get the picture?
Or lets see the Extreme programming principles. On one hand embrace change and on the other you must follow x,y,z to have a successful project(with no guarantees of success). What happens if you don’t pair program or do test driven development or whatever else is the latest breakthough in software engg? Is it that you don’t embrace change?
I think agile is best described by uncle bob , “never be blocked”. And once you accept that, the agile manifestos, the programming principles the slide guides aren’t all that necessary. True they might help, but the problem is any rigid process (agile extreme or otherwise) causes blocks.
Write junits for everything. Unit test are really low value for money. Integration tests are very hard( especially if it’s a distributed system, developed by multiple disparate teams )over space and time. All the wonderful stubs and mocks so loved by the TDD guys fail when the stub and mocks are replaced by the actual system. Which isn’t to say stubs aren’t good, but they give you a false sense of security. And can hide flaws. For e.g. There was a defined web service interface. It wasn’t ready we mocked it. All was well. Till we ran it with real data. Turns out we get stuff like ##YOUSHOULDNTSEETHIS## the xml structure is the same , the web service has the same interface but surprisingly none of us thought to write stubs and mocks that returned elements with junk values.Or what to do in that case or even how to identify them.
You can and should violate principles if the need arises. That’s agile. Embrace change. a

The Fallacies of Design

The Fallacies of Design
While reading the various UML/Pattern/Architecture/OO/XP/TDD books and literature, I think most authors forget some of the basic maladies that plague software projects. Or perhaps because there are no solutions for the problems, it is best to ignore them. So far there have been very few insurmountable problems as regards to the technologies involved in projects that I have worked on. They have always been workarounds , tactical pathworks and other hacks. But there are the other issues which can derail a project.
So here are the various fallacies I have seen

1. There is a best solution that solves your problems.


2. Systems that you need to integrate/interact with can be changed to implement the best possible solution


3. People within the project will cooperate with you. People outside the project will cooperate with you


4. The People defining the requirements know what they want. Once a requirement is signed of by said rule, it wont change


5. Budget is infinite, Time is infinite


6. Managers can manage, Designers can design, Analysts can analyze and coders can code.


7. The solution to any problem is a pattern/platform/approach/methodology


8. If the test cases pass and code coverage is > x% then there wont be problems in the wild


9. People will always tell the truth


10. Murphys law does not apply to software.

None of these fallacies are technical. They aren’t meant to be. Its rarely the technology that derails a project.

Design Patterns v/s Experience

While reading through TestNG and comparing it with JUnit, it is obvious that TestNG is far simpler to use and at first glance looks to be designed better (or has more features). Note I haven’t written a single TestNG test yet.
And I remembered reading , when people complained about the limitations of JUnit that JUnit was designed as a framework that could be extended. And how JUnit had used all sorts of design patterns.
Which leads us to Design Patterns v/s Experience question. I do not suggest these two are mutually exclusive. The comparison of JUnit and TestNG is not strictly fair, and neither is this a feature by feature comparison, nor an indictment of design pattern approaches. Its simply that having JUnit (and its varied extensions around) allowed Cedric to create a better framework. Like not having to implement a class or interface for your tests. The different ways of running setup (as opposed to the design pattern used by Gamma and co.) . And while a catalog of Design Patterns exist, how do you quantify or catalog the Experience that allows you to select the correct Design Pattern?
Experience also teaches you when design patterns need not be used. (oh yes there are cases, but I leave that for a separate entry).
And if you had to choose a candidate with Design patterns on his CV(All candidates know factory,singleton,value object, dao and session façade) or one who seemed to have the experience, choose the guy with experience (This has nothing to do with 6 yrs experience and no DP in CV!)

Youth And Responsibility

Its obvious to anyone who thinks about such things that the only hope for the future are the youth. The big picture aside, lets look at youth only in the context of the workplace. Its also painfully evident that no one trusts the young trainees just out of the trainee program.
We are of course polite. They dont have enough experience we say, we cant risk it - what if they screw up on production?. We(the experienced people, the guys who have seen it all) can't spend all our time reviewing what the trainees are delivering. In other words it is easy to find rational arguments which prevent us from delegating responsibility/tasks to the young 'uns.
The plain truth is that we don't trust them. Or we trust that they will screw up.
Which is a sorry state of affairs.
I need to break out of this mental block . And I think I'm still someone who trusts the younger people around him a lot more than others.
But it has to improve

The Anarchist Management Model

One of the things that keeps occupying my thoughts these days is how much that we learn from life can be applied to our work.
One of the major problems in work can be summarised as Management. Most non managers would not hesitate in calling Management evil , and only perhaps were we really feeling charitable would we call Management a necessary evil. But Managment persists as a practice , even worse you have younger generations(am i really this old?) growing up wanting to be managers. You have people joining the project stating that they want a management role.
As such I'm against all sorts of management in principle. I think this has to do with the fact that as a form of governance I prefer Anarchy. And currently Management is a pseudo democratic dictatorship. You dont really have a say on who is your manager (hence a sort of dictatorship) but perhaps results /feedback can get the manager removed.
Id like to see a project where people take responsibility for their actions. Divide the work amongst themselves based on their competencies. Set targets for themselves and meet them. Resolve their problems without needing outside intervention.
Could it Happen ?

Culture and Design

Does the culture we have been brought up with affect the design work we do?
Case In point.
One of the clients of my company is spending large amounts of money to attain homogenity in the technology/platforms/systems it uses to avoid the integration problems that arise with heterogenous systems.
My personal preference has always been to develop systems independently using whatever is best for that system. And then figure out ways to integrate them.
Both approaches have their shortcomings and advantages of course.

Im wondering if the fact that diversity that is so much a part of Indian life has anything to do with my preference. If so i'm grateful for it.

Interviews

One of the things that is part of my my workstack is obliging Recruitment whenever they want some J2EE interviews conducted.
It is a highly painful experience.
On one side we have the questions that we are given to ask by Theoreticians who seem to be detached from real world programming (what is the output of i++ + ++i or how many overloaded constructors does the File object have - note these arent really questions we are supposed to ask , but you get the idea) .
On the other side we have the candidates. It looks like they come prepared to answer questions like the above. And because I always begin with what are the technical details of your project and what did you work on, 9 times out of 10 the candidate looks back with a blank stare. Or provides some inane details like There is a login screen , the user enters his password and is taken to his homepage. The End. I am not alone in this regard. Other people from my company have expressed similar sentiments. Perhaps the reason is no good candidates are applying to my company :-) .
This actually leaves only one way out if we want competent resources. Hire people out of college. Train them and then mentor them.
It remains to be seen how successful this will be