Edge of Chaos - Latest Comments

Re: The Future of Agile Software Development

Quim Pagans Garriga — Wed, 16 May 2012 04:21:06 -0000

Great article Michael!!!! and congratulations for your service!!!

Re: Why MS Project Sucks for Software Development? Part I

Eladhh2003 — Wed, 16 May 2012 03:48:47 -0000

Hi Bryan,
I am trying to integrate MSP - SAP - hours report tool throw a "fronted report screen" that will update the project tasks & SAP system and will be updated by MSP too. (two-way)

Re: Patterns for Information Visualization

Karantleo — Mon, 14 May 2012 10:26:14 -0000

Nice write up. Your attention to importance of visualization shows in your product (TargetProcess) which we and our customers love to use. And we don't even use it for software/web development, but rather for ERP projects (SAP in particular). Works great.

Re: A Curious Company

Don Dwoske — Sun, 13 May 2012 12:06:47 -0000

" I jump from subject to subject and read quite random books from disciplines barely related to my actual work. I know that and I’m trying to fix that."

Why do you think that needs fixing? Maybe you can get more efficient, but learning about areas different from your daily work is extremely rewarding - particularly to someone with learning as a strength, and very often provides a foundation for important ideas. I think it's also beneficial to expose yourself to pseudo-random information - try to seek out things you would never normally come across: browse new magazines, random wikipedia articles, etc.. only once in awhile because this kind of thing can be time consuming and feed procrastination.

Narrowness of experience leads to narrowness of imagination. -Rob Pike

Re: 5 Reasons Why You Should Stop Estimating User Stories

Graham Ashton — Sun, 13 May 2012 05:14:00 -0000

"But are you sure that estimates really provide any value? Most likely not."

How you approach your estimates will have an impact on the potential benefits. When I estimate stories I go to town. I think carefully about how I'll implement them in the context of the code that has already been written. That usually requires me to open my editor and think through a possible design. I then write a few bullet points to capture the implementation I came up with, and use those bullet points to estimate the story.

I don't think of it as "estimating" so much as "research". At the end of the research I just tot up the time required for each bulleted task and stick an estimate on the story. The estimating itself is quick; the real value is in the research.

There are three clear benefits to this level of research.

1. The entire development team is involved in the research. All developers can see which areas of the codebase people are working on; communication increases amongst the team members, initially non-verbally. They soon start chatting when they see they're working in a similar area to another pair, or see an opportunity to help each other out.
2. Surprises (e.g. refactorings that need doing) are discovered before the planning meeting. The team/product owner is therefore prioritising based on a more accurate representation of the time required.
3. I agree that an estimate you have little confidence in isn't that useful. Having put the time in to work out how complex a story is, I can be very confident in my estimates. Estimates that everybody believes in are *very* useful. As non-technical team members see developers repeatedly delivering on their estimates, the trust they have in your predictions allows the team as a whole to tackle more adventurous projects.

Re: Faster. Faster. Faster.

Agile Master — Wed, 09 May 2012 14:33:04 -0000

I have found the doing multi tasking has proved to be a really big evil. Some mangers thought developer can spend 40% of their time on one project and rest on other. That does nothing but leaving developer confused what is priority and when to do switch over and also a mental context switch needs to occur before you really get into one project to another.

BTW if you dont mind can you please put this in a typed text diagram instead of handwritten ...some bubbles are really difficult to read ;)

Re: Visual Project Management

Java Developer — Wed, 09 May 2012 13:17:58 -0000

We rarely used gant charts, however we always try to use the schedule and overlapping task have always been a place where we had to do a deep review, since it slipped out some place or other.

Re: How we work: the insider’s look

Java Developer — Wed, 09 May 2012 13:13:55 -0000

Nice to see you guys have fun working, I miss my last company where we had a similar environment for work. BTW the cat got a really nice shot on the table :)

Re: Patterns for Information Visualization

Web Designing Bangalore — Wed, 09 May 2012 00:07:25 -0000

I liked the infographics.

Re: Keep Me Company

Web Designing Bangalore — Wed, 09 May 2012 00:06:45 -0000

Hi Denis, it's just your determination towards your goal that decides if it gets hard and boring. Weak determination = hard and boring.

Re: Keep Me Company

Web Designing Bangalore — Wed, 09 May 2012 00:04:55 -0000

Start is exciting and in half way it gets tiring or sometimes end up giving up in half way, but that's loser's attitude.

Re: How we work: the insider’s look

Web Designing Bangalore — Wed, 09 May 2012 00:02:23 -0000

This is wonderful.

Re: Learning & Software Development. Multi-skilled Developer

Jeffrey Briggs — Sat, 05 May 2012 03:06:32 -0000

I like your points to which you made to three levels of learning, even I believe that first thing is to learn by yourself after that comes everything else. Once you manage yourself you will easily get to learn in a team too.

Re: Patterns for Information Visualization

Michael Dubakov — Thu, 03 May 2012 14:52:58 -0000

Jason Coudriet Thank you, Jason! That is exactly our goal for TP3 - provide great mix of visualization and interaction. Initial prototypes we have are just awesome (and I rarely so positive about our own work :) Current UI in TP is quite poor on that matter to be honest...

Re: Patterns for Information Visualization

Jason Coudriet — Thu, 03 May 2012 14:46:09 -0000

Great article! Over the past year, I've become more interested in integrating infographic style elements into some of our products. As a customer, it has been great see your product evolve to nicely mix visual display of data with the ability to interact and adjust it.

Re: The Future of Agile Software Development

Donnie Nelson — Mon, 23 Apr 2012 09:05:26 -0000

An array of development languages and libraries along with agile methods has allowed us to escape of old software development dogmas. Just a few excellent technical engineers can now efficiently build systems of excellent complexness.

Re: 5 Reasons Why You Should Stop Estimating User Stories

Michael Dubakov — Thu, 19 Apr 2012 08:50:33 -0000

@Michal Mally We work this way last 2 years.

Re: 5 Reasons Why You Should Stop Estimating User Stories

Michal Mally — Thu, 19 Apr 2012 08:34:55 -0000

What you say sounds like Communism - perfect... but just in theory.

Re: Keep Me Company

Olga Kouzina — Wed, 18 Apr 2012 04:26:50 -0000

Sure! I wonder why people quite often forget this simple truth :)

Re: Keep Me Company

Andreas Groß — Tue, 17 Apr 2012 15:28:38 -0000

Olga, so true! Everybody remember please that you spend more daylight time at work than with your family and friends. So shouldn't everybody prefer to work within a joyful environment?

Re: The Future of Agile Software Development

Scott F — Mon, 16 Apr 2012 15:36:49 -0000

"
If we do the right product right, but slowly, we might miss out on market opportunities. What if we run late and there’s a reality shift, and no one will need our product anymore?"

This is a HUGE red herring. Agilistas like to parrot this but it is patently absurd.

Even if you do the right product quickly, when there is a reality shift you will sold only a small number and be stuck supporting a product that will never see another sale. If the business requirements shift so quickly that a few months will mean that it will not be needed then you have built the wrong product just as assuredly as if you had written the wrong product from day one.

Re: How we work: the insider’s look

Luke W — Wed, 11 Apr 2012 16:54:49 -0000

We couldn't believe the shift when we too moved to Pi minutes. Cat efficiency increased by a purrtrabyte immediately.
You got me too, now that april fools has flown past, was just about to start researching Pi minutes ...

Thanks for the laughs.

Luke W
www.onedesk.com

Re: How we work: the insider’s look

Steve — Tue, 10 Apr 2012 09:43:45 -0000

took me until the very end to realize this was posted on April 1st...

Re: The Future of Agile Software Development

College Automation Software — Tue, 10 Apr 2012 04:27:16 -0000

I use the php side of it to create an web application that supports
html5 which makes the web app look like a native Iphone app using the
IWeb kit. I have written a blackberry app for it in just java. the core
of it is written in java.

Re: Why MS Project Sucks for Software Development? Part I

Allen Wilcutt — Wed, 04 Apr 2012 16:17:35 -0000

Michael,

I've used MSP on huge multi-kazillion dollar projects and on small 10s-of-thousand dollar projects,

ALL SOFTWARE.

In fact, the last project was developing a BSP under LynxOS for a dual processor flight controller for a ... thing that goes boom in the night [I'm keeping the suits from knocking on my door at 3am].

Some notes:

1. MSP is not for engineers, it's for PM and management people. We don't complain about it [much] but engineers hate it. You should hate it, it is counterintuitive to your experience.
2. "There's an App for that!" Well, same applies for PM... MSP isn't for every project. Chances are, there's a PM tool for your kind of stew.
3. MS Project's biggest short coming [all Sw PMs complain about it] is no linkage to issue tracking. No "real" link to Bugzilla, GIT, SVN, heck even MS's own version control system. No linkage to DOORS or other requirement tools, either. Clearly, MS P is not suited for the kazillion-dollar government project [which will fail, as they do 19 times out of 20.. including my BSP project... Thank you Obama for laying me off... but that's another story!]
4. MS is a PM tool dispite what others here say. You track project contstraints--- time, cost, quality and scope. That's a PM tool. You can use it as a scheduling tool, "John makes bomb, Bob presses red button" if you want but that's just a small part of it.

If MS P is changed in anyway, integration with other PM tools would be the way to go. I ended up on this blog in search of a Bugzilla-to-MSP tool (and Projzilla crashed on the first run so don't bother suggesting that thing). But there are other MSP-like tools (Rhapsody) but they are far more expensive (Rhapsody=zillions of dollars) and I have to stay on the cheap.

Good luck to you.
Bryan, DC.S, PMP