Here is a post about a software company (that does not need this level of security — they are not doing secret govt work or sensitive corporate work) that has been informed about some new security measures coming along:

• No cellphones
• No Internet
• No USB storage device of any kind (this includes iPods)

This ought to make the software developers happy!

Why bother letting them use the power of the Internet and Google to get their work done better?

Maybe there are some cases where such measures are needed. However, I tend to trust first, rather than act accusingly first. If the company has such little regard for the ethics of their employees, they should fire them all and hire new ones.

Maybe what should be done is have a place where evil employees can go to:

• Smoke
• Use cell phones
• Look up stuff using the web
• Looking for the fastest way out of that job

If you work in a place like this, you should seriously consider appealing to management to have a sense of sanity and rescind such stupid mandates.

Or better yet… mandate that everyone have encrypted emails and all files must be encrypted. You refuse to email anyone without full encryption. Set up a key server and have everyone create a key, then have a key signing party. So even the smallest and most trivial of communications must be secured with big-time security! If you work with business people or other developers around the world, treat everything as if it is national security — like spies.

Or, just get a job at a better place where you get treated with respect!

Money isn’t everything 😉

it seems that some folks like to pay attention to details and the impact their code might have on the project or others’ work. this is helpful.

other times, changes are made that are seemingly unilateral, weren’t on the issue list, and cause problems.

some of the problems are subtle breakages of page layouts and aesthetics in other parts of the app. usually this is due to not thinking to check what other code is using the code that you just changed!

a bigger problem was when a developer completely removed a second data source. this ended up causing the product manager to notice that a major function (that which showed multiple data source values for a given property) was “missing.”

so, now to figure out how to gently teach folks how to be a bit more cautious in their free-grazing.

had a nice reminder about some simple testing techniques with a stopwatch/log file timestamps.

we are working on a distributed webapp that includes normal ejb/sql persistence, an in-memory jena semwebby set of models (triples+1), and blaze rules.

with some creative use of killing the development server to clear memory, running code to clear tables, and including or excluding running rules, we had the makings of some simple macro-level tests.

what we found was that consecutive runs caused a linear growth over time. Hmmm.

well, “consistency is a quality all to itself” i always say! at least the performance issue can be tackled and measured and improvements can be detected.

Turn off rules. We found that running rules caused a discrete delta performance hit. Allowing the database to grow had negligible effects on performance.

two new issues in jira!

• keep the in-memory jena models cleaned up after their use is no longer required.
• examine performance issues around rules

it is funny how easy one can get fooled by apparent coincidences in software development troubleshooting. three people. three similar issues with getting an app up and running after, apparently all pointing to the same culprit jar file.

things worked on friday… did an update on sunday, errors. yet the system works fine on the dev server. hmmm.

upshot was that fred’s error was that he was running his own build (i’ll save commenting on that for another blog post), and didn’t even have the jar. but since he knew i had the same apparent problem, he became fixated on some other cause.

my error turned out to be really weird copy of the directory in a weird location (that i didn’t even think of looking in!). how that happened, i dunno. i will attribute it to my lack of prowess on my new mac and i probably screwed up some linux command.

fortunately, tim came to the rescue and helped me find my error. quick directory deletion, i was back in action. his manifestation of the error was yet a third incarnation.

but on the surface, all errors pointed to the same jar file. when in reality, it had nothing to do with that specific jar file! beware rabbit holes and trick mirrors!

we were discussing how simply being “in the same room” is not enough to make for a successful project. I contended that a distributed team can force the issue of doing best practices in terms of collaboration and being very visible.

when i worked with a team in St. Petersburg, RU, I would be onsite 2 weeks per month. i would have been more effective being onsite 100% of the time. (We were developing software products at TogetherSoft.) However, being a distributed team meant i had to increase the level to which we ensured we always worked by being open, communicative, and extra visible. so, we were more certain to have collaborative tools…

• tools to control the features — not a bunch of cards physically limited to sitting in some room.
• models and design ideas on wikis — not just on a whiteboard
• design by interface to avoid dependencies whose impact can be exaggerated in distributed team dev
• web meetings to discuss items with the team (usually said documentation and design ideas)
• plans and progress visible in wiki

the benefit? this not only served the local purposes of the team, but it was useful for anybody else who might be interested, or who wished to collaborate — without having to be in the same room (or continent). Also very useful for newcomers to join the project mid-stream.

some teams would be content with doing just enough to meet their local needs. which is fine. (an extreme example might be a solo developer that does not docs or design or project wiki.) my point was that if you want to succeed and you are doing distributed team dev, you better adopt some best practices that help keep everyone on the same page. this can lead to a distributed team having to go further than a local team would in terms of building a collaborative workspace and artifacts. Obviously, nothing precludes a local team from doing the same activities, it is just that a local team need not to it to succeed; whereas, a distributed team lives and dies by proper collaborative techniques and tools.

so, while a local team can do the same level of collaboration as a distributed team, they do not have to, and often do not. the converse is not true. a distributed team will quickly fail if good practices are not followed.

maybe a corollary to my point… if you cannot do development well locally, you likely will not get any better results when you add in 12 time zones.

we have been doing agile development with teams across 4 continents now… with success. sure, sometimes i wish we were together, but skype and other techniques can help bridge the gap.

part of the balancing act in agile is understanding the timing of when a decision must be made, and its impact on the project’s success.

a discussion came up in the Agile Usability forum… it had to do with the UEX team wanting to ensure understanding of 3 content templates ahead of time (for a content-rich web site project), and the dev team advocating for a “just in time” approach.

my suggestion… if it is costly to decide on the content templates late in the game, explain it to the dev folks.

or conversely, have the dev folks explain how the template choice has no impact on the timing of dev and cost.

bottom line, talk! have people prove to each other one way or the other…

sometimes, we “architects” can design systems in such a way as to squeeze formerly “costly” aspects of a traditional system/approach into trivial aspects. sometimes.

In a post on agile usability forum, William Pietri wrote about outsourced team challenges.

“Having helped shepherd one offshore project onto an agile path, I now merely think it’s much, much harder and a fair bit less effective than getting everybody in the same room.”

You have to qualify “being in the same room is more effective” — there are lots of assumptions going on in that statement

Though I know what William meant, here are some points to consider:

• being in the same room and in a culture that does not value communicative development techniques has little benefit. except, it probably slows the project down due to chit chat
• being further apart can have the unintended consequence of engendering greater degrees of communication — because you have to.
• being further apart can lead to beneficial practices such as:
  • teams designing to interfaces,
  • following more general architectural visions,
  • following the pattern of a thin slice of working code,
  • making more of an effort to keep the team communicating daily across continents,
  • etc.

With a discussion on Agile Modeling forum about organizations seeming to have issues with properly applying agile ideas, I proposed the following:

agile is:

• more a state of mind, than a set of steps
• a technique designed to reduce the gap in time between doing something

  on the project and seeing the result

• a way to better shepherd your resources to meet your goals
• a philosophy that requires more — not less — use of gray matter at

  every step of the way

agile modeling, agile processes, agile coding… they all fit in there

somewhere

here is a *null* hypothesis. let’s see if we can disprove it:

“agile requires being smarter than average. therefore, agile only

succeeds in projects that have people that are smarter and more

experienced than the average developer/business. ”

Not sure what to dub this… But here’s the situation. I have been doing some EJB/JSP/JSTL coding. Partly looking at some existing source and refactoring, and designing and coding a better mousetrap myself.

One chunk of source code was full of code in triplicate (including repeating all of the fields in multiple JSPs), or code that was 99% the same as a base class/action. Mind you, this code is for handling displaying, editing, and creating new objects for a 50+ class model. If it were for one or two classes, I almost could care less how it was written.

Maybe I am old school. Maybe it is from years of C++ and early Java. Maybe I am lazy. I don’t know. But to me, I look to eliminate these design smells and reduce repetitive code. It is also a factor in making the code easier to understand and maintain down the road. I scratch my head wondering why the developer thought that this was the easiest and best solution. I would beat myself with a stick if, as I got into implementing a design of mine, it turned out to be a nightmare. I’d go back and try to improve it. A matter of pride? Not at all. A matter of trying to do it more efficiently (or call me lazy).

While refactoring is a way to catch this, it is also a matter of when to refactor. Doing it after 50 things are already triplicated is much more difficult (and budget busting) than catching it early on in the design and testing phase.

This work was done in a distributed team. Name of the game here — if the developer had no pair — is to have a point in the process where the code design is reviewed. Another pair of eyes might have spotted this early on.

On the Straight-Talking Java forum, Miles Parker mentioned helping friends with “computer” issues.

I rarely dread calls more than from not-so-tech-savvy friends and family. Not because I don’t want to help, on the contrary. But more because of the myriad ways that Windows and Windows apps can become spectacularly fouled up down in the bowels of the machine.

Sometimes the issue is trying to figure out what happened that caused their entire year of their small business financials to disappear. Coincidentally after Windows did an auto-update — and I suspect auto re-boot during a long-running backup process. (BTW: data was lost.)

Or how my own out-facing network address made it to the spam blocker list which in turn caused my own outbound email to sporadically fail with strange messages! Thanks girls… glad you found those wonderful trojan viruses that were spamming from one of your machines! I made the firewall and virus protection tighter.

Now on to migrate over a desktop PC to an iMac — xfer email address book, personal files, etc. Should be loads of fun. After all, I just made a first pass at exporting Address Book from Outlook and it said the Export feature was not installed. Yikes, I’ll have to break out the original install disks.

I’ll let you know how it goes!