Sunday, September 30, 2012

I ripped through the Mythical Man-Month

[Update] You cannot read MMM without reading "Death March -- Yourdon". I just skimmed sections named "Good Enough" and "Best Practices, Worst Practices". I will have to rip this book shortly.

I was given my first copy of this book when I was a contractor at IBM. The manager that loaned it to me was a good person and an effective leader, manager and architect. I ripped through parts of the book and gave up. Brooks is a fine writer but some of the stories were just a little too slow. Also,  for my taste, once you acknowledge that the writer is credible and provides reasonable references then I get lost in the arguing over the minutia.

What is also interesting that this tomb tome was accepted as gospel in the 1980s. A lot of the information in the book is still consistant with my personal experience but someday it may all be regarded as false. For the moment I'll keep my one page summary as the summary I might use when my intuition checks out.

One Pager - The Mythical Man-Month -- Brooks

The Tar Pit


There is good and bad in large system design and implementation. They are what keeps us going. Creativity of design and programming and the need to be perfect every time.

The Mythical Man-Month


Estimating is hard and futile. Disasters are common. (1) estimating is poorly developed and predicated on ongoing success. (2) confuse effort with progress. (3) monitoring is poor. (4) schedule slippage is expected. "adding manpower to a late project makes it later". "The number of months of a project depends upon its sequential constraints." and the resources needed to implement them.

The implementation formula for planning, coding, testing(component, system).

The Surgical Team


A similar observation to Agile; a wide variation between good and bad programmers. In a surgical team there is specialization.

Aristocracy, Democracy, and System Design


The design must come from the mind of one or a small group. The implementation by many.

The Second-System Effect


The second system is always over designed.  It's an important exercise to design and learn from but not implement.

Passing the Word


Make sure that what the designers describe is actually what is being implemented.

Why did the Tower of Babel Fall?


Failing to communicate with a large team. In modern concepts we'd be talking about internal blogs, wikis and webex. Effective communication is key in terms of timely, content, and complexity.

Calling the Shot


Through a lot of programmer productivity research and data collection... Portman, 50% of the projects take 100% more time. Aron and Harr, separately confirm that productivity is relative to complexity. OS/360, confirms Aron and Harr.

The more interesting data was from Corbato, productivity  is constant in simple assignments. Productivity is increased as much as 5x in suitable high-level language.

Ten Pounds in a Five Pound Sack


"Like any cost, size itself is not bad, but unnecessary size is." In today's GEM happy Ruby and Rails programmers just install whatever they need without thinking about this. Deep dependencies have a high cost.

The Documentary Hypothesis


Project documentation may feel like an unnecessary burden but it's crucial. It's a contract from the design to the implementation. It's a contract with the stakeholders. It's a contract for the testers. Format and consistency is important.

Plan to Throw One Away


"in most projects, the first system built is barely usable" So the real question is when do you throw away the prototype. "plan for the system to change", "Plan for the organization to change".

Sharp Tools


This chapter is a little dated but the message is still the same and important. You need tools to be effective and efficient. Whether it's a Wiki, Blog, Bug tracking, continuous build, integration and deployment. You need the best, or at least good, tools.

The Whole and the Parts


Develop a roadmap, validate the roadmap then start building the road. As the system takes shape test and debug the smaller components. Assemble or integrate the components one at a time with scaffolding.

Hatching a Catastrophe


It is easy to recognize major failures that prevent a project from being completed. A building fire or a crashed system are easy. The difficulty occurs when there are minor daily events in life that cannot be made up and harder to recognize.

The Other Face


This is the deliverable. Of course there is the UX for the actual deliverable but then there is documentation, flowcharts, help. The current view

No Silver Bullet - Essence and Accident


The largest chapter so far dedicated to "no silver bullet". There have been a number of improvements from object oriented programming to code generators. None one is significant enough.

"No Silver Bullet" Refired


There has been some new research but essentially the author's position in unchanged.

Propositions of the Mythical Man-Month True or False?


If you do not want to read the book because it's too detailed or long and this doc does not provide enough info, then this chapter is for you. It's essentially a recap of the book based on today instead of 1975.

The Mythical Man-Month after 20 years


If, however, you are more interested in what might work or where Brooks admits he was wrong. Management must act deliberately and with purpose. You must have an architect for conceptual integrity. Second system has some conflict. He never considered the modern GUI desktop. It was too simple to say throw one away. It's more than that. Incremental build is good (a not so modern tool). Information hiding is good(info shared between teams). There are a number of other reversals in this chapter.

Saturday, September 29, 2012

Resumes, GitHub, Blogs, or Social

What a mindbender! Yesterday I read a Hacker News headline that suggested resumes had no value. Today I read an article from a former Facebooker who said blogging and social were a waste of time to concentrate on developing something good. And there have been countless sitings of GirHub hires in recent months.

I've written about the hiring process many times in the last 12 months. So in response to those writers: ARE YOU KIDDING ME? C'MON MAN!

First of the hiring process for any employer you'd want to work for is never as simple as RESUME=HIRED. There are so many steps that need to be performed before and after the interviews. It's one of the many reasons that companies insist on "contract to hire" as well as extended probationary periods. In many instances the resume has become "the cover letter". While some employers still like cover letters they are not so much about the content as they are about demonstrating genuine interest in the potential employer. The same can be said for just about any hoop they make you jump through.

A GitHub reputation, by itself, is not a strong indicator. One of the things you'll hear on any bank or investment bank commercial is something to the effect "past performance is not an indicator or guarantee of future performance". The same can be said for a GitHub reputation/score. Let's not gorget that while this appears to be an objective number it is subject to electronic analysis and could easily be gamed.

Blogs are also a tough one. When your hobby and career are one in the same thing... and you are not self employed. It is possible to upset someone for having a public opinion that might be contrary to what is happening inside the workplace. That guy from FaceBook probably got fired for not knowing when to keep his trap shut.

Blogging is one social aspect but using 100% social or marketing to land that next job will likely also not work. Everyone has circles. Are you sure that it's a good thing that the circles overlap? Really?

None of these things are good on their own for landing a new job. You have to do them all. There are not magic pills or spells you can cast. Finding a good job, even a great job is hard work. The odds that someone is going to hand me or you a blank check are less probable than winning the lottery. So play the lottery.

Who makes your security decisions?

I'm sitting in front of my kid's Chromebox and I thinking about a password for her. It's not that big of a deal and I could go crazy if I like. I can also go really loose. But as I'm sitting here I wish I could use this computer to monitor things at work.

For the price or a Chromebox I can go mobile with much less fear about losing my computer because everything is on the network and there is nothing locally. The machine weighs much less than the standard issue laptop. I can also implement a 2 step/part authentication. and so one and so on.

But as I think about security policies. I wonder who is making the decisions and when they make those decisions; what level of friction are they comfortable with. For example if you are a CIO of a company and you have implemented lax security measures and you are compromised then you will likely lose your job and your rank. Not to mention that there is likely to be some legal fallout. So my guess is that if you are a CIO and making the decision there is going to be a lot of end-user friction.

On the other hand if you are a low ranking manager responsible for security you are likely to make thinks geek friendly. Allowing people to connect to the company's resources with their personal computers or tunnel through the firewall. Reverse ssh from internal computers in an almost wild west setting.

Somewhere in the middle there is the HR policy maker. I'd like to think that this can go either way but usually falls toward the more friction side of the equation.

Who makes your security policy decisions?

  • Federal, State, local laws and ordinances?

  • Bureaucrats, think tanks, Solution vendors, or 3rd party consultants?

  • Company Executives or senior management?

  • Middle management or IT departments?

  • Security by Committee?

  • Technical or Non-Technical employee?


What sort of UX Friction is there?

  • Exclusive VPN with no external access and limited internal access?

  • Dedicated Citrix remote desktop running on dedicated Wyse terminal?

  • Normal VPN with limited access to internal services

  • SSH or Tunnel

  • Robust applications acting as proxy

  • and so many more


I still wish I had the network privileges and tools to do my job from my kids Chromebox.

Friday, September 28, 2012

I like everything TURBO!

my introduction to programming was BASIC on my father's TRS-80 Model 3 back in the early 1980s. Shortly after that the IBM PC was introduced and I started writing C code using edlin. But was not long after that when Borland International introduced me to Turbo Pascal, Turbo C, Turbo Assembler, and Turbo Prolog. They might have had a Turbo Basic too, however, but then I was on to other things.

So when a company or team introduces a product, application or library with Turbo in the name it's hard to resist the temptation to be an instant fanboy. I do not know anything about TurboLinks but I'm going to read the article anyway. Just for old times sake.

Thursday, September 27, 2012

The Google and Apple Honeymoon Appears to be Over

[Update:2012-09-28] One think I really hate about the iPad and iPhone is that they are linked to a person and not a purpose. It's one thing I dislike about the Chromebox.  Anyone can sign in as a guest but to get full features you have to be logged in. I hope the Nexus tablet is different.

I discarded the first two drafts of this post because I found myself off target and unable to bridge the gap in order to get back to my point or it was just getting too wordy. So let's look at the logic bomb a little differently.

(a) Apple is building a product brand and data access brand and silo out of it's products. With examples like iOS-6 maps vs Google Maps as an example you should see that the Apple stack is closing. The openness seems to be closing partly because of security measures like sanboxing and partly because Apple likely wants to control it all.

(b) Google seems to have all of the data. They certainly have search cornered. Then there is the cookie breadcrumbs where they learn so much more about the web stumblers. The fact that they are now into browsers, operating systems, phones, tablets, desktops should come as no surprise. They implement a number of sandbox strategies too, however, while they use a lot of standards they put up their shields by releasing BETA level code over very long periods. Not all of the features or functions for real openness are actually implemented.

(c) Amazon is the defacto cloud service provider. Most of all startups begin with private hardware for their initial development, however, most will end up using AWS in order to get the product launched. The Kindle aside Amazon has implemented the same elements that Google and Apple have, however, their implementation is virtual.

(d) Microsoft has stolen back the Apple playbook. Microsoft and intel introduced the world to a number of technologies that would have made intel based Linux and BSD impossible. Now Microsoft is competing in the OS, phone, tablet and desktop markets. Their Metro interface is interesting to dig into. I'm not sure it's right for the desktop but it might. In the meantime they have search(Bing) on top of the hardware and they have a 30 year head start on the competition.

(e) Oracle - I was going to try to find a way to slide these guys in but they're not that interesting. Sure they bought Sun for which they received MySQL and Java, however, they seem to have killed off the hardware. I'm not certain that was a wise decision. I wonder if arrays of Spark 10K systems would not compete in efficiency in the cloud. So let's strike them out. If Oracle were to buy Yahoo they would be a competitor in this article.

These are what I call the Tier 1 web properties. (i) they have a complete software and hardware stack, (ii) they have a lot of data like search and other marketing data, (iii) While there is some openness it is incomplete, (iv) their products work well together and have some unifying properties. (one thing I did not mention... now these guys are accepting payments and micropayments. Armed with the actual buying patterns and not just the search patterns this information is even more valuable. Transaction processing should be free)

Then there are the Tier 2 web properties. This tier is made of A-list applications that strictly a one dog shop. Companies like BerkeleyDB, PragProg, DropBox, Evernote, Adobe, Panic and JetBrains. These are companies that you have no problem spending your money on. The risk they would sell you out to a marketing company is low and yet the product they provide serves it's purpose well and you never feel cheated.

From here things get a little grey. Partly because it's made up of free, open source, spyware, malware, trialware, charityware, and so on. They are effectively the VHF of the software world. If only one of the Tier 1/2 would acquire them they would become legit and maybe make some money. *cough* MySQL.

So what's going on in divorce court?

The big boys in Tier 1 are preparing for battle. Their barriers are semi-permeable but not as much as when they were under construction. The Tier 2 guys are waiting for something to happen or trying to make something happen where they can. And everyone else is begging for a seat at the table.

So what am I going to do if I want an iPhone fully integrated into my Google dataset? What about a windows phone running connected to my apple desktop... and any other combination that might arise. I might like my iPhone but I want that new $99 nexus table. In fact I want several. One for each room in the house and one for each kid and one for my wife and myself. I'm not sure I'll ever be happy with the iPod, Nano, iPad price points. Furthermore, now that I'm testing a ChromeBox for my 2yr old a google solution is looking more likely every day.

I hope I'm making sense now. Clearly we are going in cycles again and the stakes are higher than they have ever been. I'm not looking to pick the winning horse. I just want a seat at the table.

Wednesday, September 26, 2012

Are Story Estimates Valuable?

Whether you're implementing KanBan, Scrum, or Agile Process Management the topic of estimates is always brought up. The question on my mind is whether there is any real value in making an estimate and /or being accurate. Clearly there are opportunities to game the system.

On the other hand what value do they bring to the stakeholders? They are going to set the timeframes based on the need of the feature and not how long it's going to take (although that can play a minor role). And then there is the project management and leadership who is going to review the numbers. But what does it mean to them and what are they going to do with it?
Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
Scotty: How long will it really take?
Lt. Commander Geordi La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
Lt. Commander Geordi La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

The bottom line: (a) stakeholders set the priorities. (b) stories are supposed to have known resource costs whether your sprint cycle is a day, week or month (c) daily reviews(standups) and periodic retrospectives are supposed to contain actual effort. So to ask for estimates is just false.

Tuesday, September 25, 2012

KanBan, Scrum, Agile Standup meetings

I recently wrote a short article on the different types of standup meetings. I hope you find it useful as it is less than a page.

Zero Downtime Deploy is a Useless Myth!

I've touched on this before referring to erlang's hot deploy functionality. In that case I was concerned with the notion that transactions would not be reproducible during a hotplug scenario. That elements of the transaction could be mismatched as the various code segments were deployed.

This evening I read a headline that some developer had implemented hot deploy for NodeJS.  Let's forget that NodeJS not currently a serious production environment and while it powers CoffeeScript and Less; I personally am not thrilled with the prospect of having to install NodeJS.

But now there is hot plug NodeJS.

I certainly get what the developer was going for but the reality is that in a production environment we, devops, are supposed to plan for this sort of thing. Our systems are supposed to have downtime.  We are supposed to reboot our systems every once in a while to make sure that we can. Every data center I have ever worked with or for has had a power outage at some point. Even the mighty Amazon AWS/EC2 has had major failures and outages.

So while a hotplugged NodeJS might be interesting or novel; on some levels it's not a real feature to bet your enterprise on.

Standup Meetings: Scrum vs KanBan vs Agile vs Other

Everywhere you go these days teams are doing some sort of standup meeting. Whether it's rigorous, loose, or even adhoc they are doing it.

  • KanBan


In the KanBan standup meeting the team is supposed to take a task centric view. That means (a) blocking tasks, (b) tasks that are risky, (c) tasks that have not made any change since the last time, (d) whatever's left.

  • Scrum

  • Agile


On the otherhand, Scrum and Agile take a resource centric view. Going from contributor to contributor... answering the questions (a) what I did yesterday, (b) what I an doing tomorrow, (c) what is blocking progress.

  • Other


Between the Agile/Scrum and KanBan they pretty much have things covered. I imagine that if anyone were to invent a new process it might look exactly like these with variations on time, scheduling, attendees, subject mater and/or magnification. So other is my catch all.

One other thing to mention is that sometimes the teams are cross functional and so the stand ups take place twice. Once in the cross functional team or cell and again in the vertical talent pool. And finally, at some point when the project is big enough the updates need to be escalated to the next level so that the information can be aggregated and the stake holders engaged to make critical decisions if necessary.

In conclusion they all have something to offer. Whether your team is going to benefit depends on the team, the mission, support and needs from leadership and stakeholders. Knowing what and how to communicate; and how to summarize and report are key to success. Let's not forget that feedback is an important part of the cycle too.

What are the minimum DB fields required in an Agile Story Schema?

I'm getting ready to define the schema for the bugs backend DB when it occurred to me that I needed a minimal schema in order to maintain the one-page requirement. I do not want to get crazy with 100's of one-off fields. Just a simple set of required fields... auto filling them when possible.

Fields in the most normal form:

  • id

  • bug_id (FK)

  • date

  • field_id [opened_by, open_date, close_date, status, importance, assigned_to, story, note, ...]

  • field_value

  • field_text


I have included field_value and field_text because most DBs have different profiles for TEXT and VARCHAR fields. So in this implementation certain field_ids will be assigned to certain field_**.

What fields would you add and still keep it lean? Would you add a separate agile state or wrap that in status?

This appears to be a good reference. It's still more info than I wanted... but it might be practical for both bugs and requirements.

Convert your Mac from a Rabbit to a Tortoise

I went to the Genius Bar on Sunday because I cracked the glass on my iPhone and the mouse on my wife's MacBook was not working (swelling battery maybe) and then there was the performance on my MacBook Air that was just sucking!

The results are in. Google drive uses craploads of memory and CPU; Little Snitch (3 beta) is not much different. As a result the system is just so super sluggish. I understand the issue with little snitch. Heck it's beta software.  But my concerns for Google Drive's performance are all over the place. They do not have an auto updater and they do not display the current version number in the preferences pane. They do not support a 'start paused' option either.

I have a number of there product concerns with GD but I'm confident that they will never be heard. I like the storage capacity and there are other tools for accessing and syncing (cyberduck) so I think I'll go that way instead.

PS: Make sure that the firewall is turned on. The latest version of OSX disables it. I'm not certain whether that has been the default but it is now.

Friday, September 21, 2012

One Pager - KANBAN -- Anderson

I should not have to justify Kanban.  If you're reading this then someone has already decided that this is the way of the future. There are plenty of images of Kanban boards on google and other search engines. It's pretty simple to implement basic and advanced boards. The complexity comes from lack of discipline to keep doing it. It's so easy to get lazy.

Five Kanban properties:

  1. Visualize Workflow

  2. Limit Work-in-progress

  3. measure and manage flow

  4. make process policies explicit

  5. use models' to recognize improvement opportunities


Kanban shares some elements with Lean, Scrum, Agile, and even waterfall. Artifacts include epics and stories. Work cycles or sprints have time limits. Teams might have multiple stand ups based on cross functional team makeup as well as roll ups.

The Basic Kanban board (extremely oversimplified):

  1. input queue

  2. analysis

  3. development

  4. test

  5. stage prod


The Basic Kanban board with buffers (extremely oversimplified):

  1. Input queue

  2. analysis (in prog, done)

  3. dev ready (in prog, done)

  4. development (in prog, done)

  5. build ready

  6. test

  7. release ready

  8. stage

  9. prod


The Kanban board movement:

  • input enters from the left and output exits to the right

  • officially workers are only supposed to pull WIP they will push into queues

  • workers pull from the queues never exceeding their WIP limits

  • When a story is removed it's because it was completed, implemented and verified in production or KILLED


The Advanced Kanban Board(s):

  • There might be an epic board which drills down to individual team or cell boards

  • Each sub-board might be parsed or forked; by vertical function or horizontal worker role.

  • Or a master board might have extra columns for individual contributors or even horizontal sub-columns based on role and/or vertical.


Standups:

  • meant to happen near the boards

  • meant to happen in public/common locations as to attract external attention

  • meant to be short and to allow commingling of cross functional conversations

  • meant to fail fast and identify blockers fast

  • create slack (whatever that means)

  • cadence promotes consistency and reproduction

  • do not really promote remote users

  • standups in team rooms do not promote global interaction

  • know the difference between a block and a speed bump. decide on a format that works for the team.

  • What you did yesterday is not really that important.


Metrics:

  • generate reports

  • measure business value (internal and external)

  • track to revenue or savings

  • detect failures perform root cause when necessary - do not use intuition


Exceptions:

  • set WIP limits

  • set queue and buffer sizes

  • limit scope to epic

  • slack used to catch up, recharge or experiment


###

Thursday, September 20, 2012

What is next for my desktop?

I'm staring at two MacBooks on my desk. One PPC Mini in pieces because of a mainboard failure. And a Macbook in the kitchen which belongs to my wife. The two machines on my desk are updating to OSX 10.8.2 and it is painfully slow. My wife's computer will not install 10.8.x because the hardware is old enough that it's no longer supported by OSX. And I have two kids who already navigate our recycled iPhones in order to play educational games. And to top it all off my wife wants me to buy them a computer.

So to say that I'm looking for a new desktop is not exactly correct. To be perfectly clear I'm looking for a new desktop for my kids. And I have some requirements. (a) I do not want to maintain upgrades (b) no moving parts (c) secure (d) inexpensive (e) reboots quickly (f) a preview of sorts for when the grandparents need a new computer.

The chromebox and chromebook are looking like real candidates. My first chromebox is on order. It should be here in a few days. I plan to velcro the box to the underside of an Ikea kids table, screw the monitor to the table. and secure the keyboard and mouse to the table too.

I'm hoping that this setup is so successful that I can replace my desktop in the office with one of these too.

[UPDATE: this project was a complete success.  Since then I have purchased my 2nd & 3rd chromebox; and now both kids have their own workstation. The instant on and auto update are the best features and they keep me out of being tech support as I would if they used PCs.]

Saturday, September 15, 2012

The book publishing world should go on a diet

Traditionally booksellers had one metric by which they measured a book's value. "The thud factor". I remember well when I first opened the 'M' volume of the encyclopedia and when I bought my first edition Petzold book. Unlike the encyclopedia, however, book authors are just like high school and college students who fudge with the margins, type font, line spacing and images in order to get the right amount of pages for the printer's template.
I want the cliff notes version of every book in my analog and digital archives.

Right now, however, I'm reading 4 different books on Agile Process Management and they follow the same basic outline. Preface, Foreword, 2-3 obligatory chapters of background or justification, 4 chapters of good information that could be distilled into 2 or 3 pages of real info, and then several chapters of case studies and a postscript.

Then there is every rubiest's favorite, "the pick axe book". It's 700+ pages of all things Ruby. That used to include gobs and gobs of standard library references, 3rd party library references, preface, foreword, a "section" justifying the language and the book, with stories about what was cut in the current edition. Don't get me wrong; I have 2 or 3 editions here too. And I still have not been able to complete it.

But here is what I want.

I want the cliff notes version of every book in my analog and digital archives. I no longer have the time or the inclination to read all the useless cruft that authors and publishers throw at us because they think we need it. There is a reason why there is a "data structures" class in college. It's because they are teaching the base concepts and not how a specific language implements the base concepts. It's the students job to learn how to learn. To know or try to apply those concepts to any and all languages. When I was in college the course was called "data structures in Pascal" but when I took the class I wrote my assignments in C. A few years later Sedgwick rewrote the book in C.

So the real question I'm asking myself is who are these books written for? Are most book buyers novice or journeymen? At the end of the day I look at the amount of documentation that Rob Pike and the rest of the Go-Lang team produced and I'm in awe. They have effectively produced:

  • table of contents

  • language reference

  • tools reference


and Separate:

  • standard library reference

  • 3rd party package links/repository


All concise and nicely linked to online. I have a mind to reformat the docs into a one or two pager... just to prove that it can and should be done.

Friday, September 14, 2012

Pair Programming - shared experiences

I'm not a fan of continuous paired programming. There are a few cases where it makes sense. (i) new employees, (ii) rookie programmers (iii) certain rapid development cycles. However, sustained two users and one keyboard is simply not practical unless it's full contact MMA style.

There are a few other interesting offshoots. (a) Real-time file sharing (see subethaedit and coda) (b) splitting the coding into dev and test but coding in parallel and together. This can be even more fun when you add a third person who it structuring the module's API signature while the others fill in the blanks.

Pair programming is not meant to be arm chair programming or back seat programming.

MDD and DSL - I feel like I'm circling the drain

Have you ever seen one of those charity boxes that looks like a large funnel and when you put your coins in motion it goes round and round until it falls into the center hole only to be collected by the charity's processor. Looks something like this. Well when I think about MDD (model driven development) and DSL (domain specific language) I feel like the coin going round and round.

MDD and DSL were and still are viable tools for deconstructing systems and processes that are to be implemented in hardware/software but to fail to recognize the history is pure folly. Many years ago they were referred to as DFD(Data Flow Diagram) and FFD(Funtion Flow Diagram). Sure, back in the day, we used analog systems to capture the details and now it's digital but the results were exactly the same.  In fact even if you say that MDD is the new and improved DFD.... it's new and improved in terms of same box of PopTarts with just a little less filling.

And so now I wrestle with OO.next(). Object Oriented programming was and continues to be leap years ahead of DFD/FFD and the jury would seem to be out on any comparisons to MDD/DSL. So instead let's jump ahead another generation. What is the next version or incarnation of OO going to look like and is it ready for some early adoption now?

Wednesday, September 5, 2012

Self organizing teams are costly in other areas

The Agile process is suppose to accomplish a number of things. Sustainable development is only one of them and that truly depends on the team. The challenge, however, is that "team" is not a static thing. Employees leave and join teams regularly. Whether by normal attrition or because of success in the business and the anticipated or realized workload. Sometimes it's a matter of cross training members in other teams that could benefit from knowing more about the whole instead of just a few parts.

But one of the tenants of Agile is that the teams are supposed to be self organizing and that suggests that teams are self regulating as well as adapting the process as the team sees subtle or obvious customization. And it is this customization of the Agile process that I'm concerned about. For example when you are RUP trained you can be interchanged from one RUP team to another so that you can concentrate on the domain specific challenges on not the internal processes.

Furthermore, since Agile teams are flat relative to traditional organizations it promotes the notion that advancement comes from moving horizontally instead of vertically. Unfortunately moving horizontally has it's challenges when moving internally and externally. It too becomes another system to game.
The only constant is change... --Issac Asimov

If you have been in this business long enough you have come to expect change as a fact of life. However, in a physics context; change causes friction, friction causes head, heat causes premature aging... etc. And let's not forget excessive heat. So the point I'm circling around is that Agile is it's own worst enemy. Yes the glossary is fairly similar but the execution is not guaranteed.

Tuesday, September 4, 2012

Getting ahead of the pack in an Agile world?

I just bought 6 books from PragProg adding to my expanding library of eBooks on the subject and taking some cues from real life and experience I want to know "what is it going to take for me to receive the highest salary increase" when salary adjustments are handed out?
However every industry has it's laborers and architects --Richard Bucker

Historically salary adjustments had many different names. (i) cost of living increase (ii) merit increases (iii) bonus and so on. And in pre-agile times managers would rank employees. First everyone might receive a basic or flat rate adjustment ... for surviving the previous year or as a part of profit sharing. And then, using the ranking, the manager would increase the employees from a shared pool at the managers discretion based on any subjective or objective criteria.

However, in an Agile world where managers are supposed to be looking for marathon like sustainable development, what criteria should a manager use to rank or reward employees? For some employees overachieving comes naturally, for others it takes a lot of time or effort. The former will demonstrate sustainable performance and maybe some personal growth. The later will eventually burn out. Since the goal is sustainability it is going to be incumbent on the manager to NOT burn out the employees, therefore, either the bar is set lower to accommodate the average employees or only the best will do. (However every industry has it's laborers and architects)

The fantasy world of Star Trek is based on a meritocracy. If you have the aptitude to be a starship captain or a gardener you'll be assigned to that task. As for actual compensation I cannot remember it ever being discussed except in the rarest cases. Agile would have you believe that a meritocracy exists in this world too. If it is them maybe we are actually in transition... and while I cannot tell whether it's a good thing or not... I want nice things and I want to make sure that my employees can have nice things too. But for this to work I need to reward them somehow.

Monday, September 3, 2012

Is the JVM a viable release platform?

I have written a number of server applications based on Sun's JVM and luckily for me I have not had to code anything beyond a few interview questions under Oracle's stewardship. In the last year or so Oracle has released two versions of it's JVM with well publicized security holes. Normally this sort of thing would go unnoticed or at least pass quietly so what does it mean?

Back in the day when Sun was touting the benefits of Java it was "rewrite once and run anywhere", "the network is the computer" and security. Whether "security" is defined by phone home, crypto, private and protected modifiers... or the effects of recent attacks you really have to start thinking about Java a little differently.

So when I watched an interview with Rich Hickey this weekend where he talked about Clojure, and by extension Datomic, just plugging into the JVM on your local machine I could not help but get a little concerned. First of all while Clojure is interesting and probably functional and plenty of first-class implementations of things... the hangers on and other libs still use basic JDK libs thus infecting the pure implementation(see that Lift embeds Jetty). And while Clojure is supposed to implement similar read-only features of erlang and other functional languages... what happens when the JVM is attacked sideways?

I like java for what it is and what it might be again. I categorically disagree with some of the language features that are clearly designed for the proprietary sect of this business. And frankly so many more have accomplished much more with less effort using dynamic languages like Ruby, Perl and Python.

One of my strongest beliefs is that in order to scale you need the following: (a) a reasonable ROI on the initial development. (b) ability to automate administration/deployment of the second wave of hardware. (c) ability to automate the automation of the crazy scaling where the application, infrastructure, and people scale organically. At the end of the day scaling must be achieved by applying the lessons of Henry Ford and the assembly line.

Saturday, September 1, 2012

Having worked with driptiles. metro is interesting but has limited usecases

The description that follows is derived from my experience with droptiles. What makes droptiles interesting is that it is browser implementation of the metro interface as generally described by Microsoft for Windows 8. I cannot begin to determine what sort of accuracy there is between the two but it is interesting to use and modify.

The way droptiles implements the individual tiles is effectively that of a porthole on a cruise ship. (a) you can see out the window at the limited and effectively prescribed view, (b) if you want to see more you have to get off the ship.

The tiles on droptiles are simple views that you allow the user to see, They are implemented in fixed sizes but can be anything you can render with private css and/or Twitter's Bootstrap. Optionally, the user can add tiles from the "store" and the user can move tiles from one section to another or within a section. (some of the auto placement is a little awkward and buggy.)  Also, if implemented the user can click on a tile and the website that is linked to the tile will take over the current browser tab inside an iframe. (The iframe is to give the user a way to get back to the main droptile dashboard).

So in summary you either have the dashboard up in fullscreen or you have the app you are using in fullscreen. This is ok for someone who might be a casual user. Possibly someone at home on the couch that is watching TV and casually looking at RSS feeds or even email blurbs. It might be useful to someone in network operations or some other role where the main job responsibility is to observe and report. But as a programmer, knowledge worker, or just someone who might perform word-processing all day... the droptile metro interface is not going to add any real value.

So I wonder whether the ongoing complaints about Metro are well deserved or not. I wonder whether or not the start button is really necessary or not. Will wonders never cease? Given the size, depth and breadth of the average user's program files folder I wonder if this is good for the desktop? It's certainly great for their phones!

another bad day for open source

One of the hallmarks of a good open source project is just how complicated it is to install, configure and maintain. Happily gitlab and the ...