In reading this very nice post from Manoel Pimentel Medeiros, I am reminded of another value I ascribe to simplicity — “quick-and-dirty” can be a valuable technique.

Many times, when faced with some very complex issues in my projects (usually surrounding integration with bizarro other systems), I strive to have developers take a very simple approach at first. Sometimes these approaches seem like hacks, inelegant, and the exact opposite of what I normally practice. Sometimes I can tell it is hard for the developers to do this “ugly” work. (Maybe they fear I will leave the ugly hack in place .)

However, this is a technique I use when the route is not clear, or when there are viable alternatives from which to choose. Or if we are probing for the right solution and are not confident if the chosen solution will work. So, instead of designing a more complex and elegant “correct” solution, I do the simplest thing. Maybe it means dummying up the data to achieve the effect. Maybe dummying up some objects. Hard coding. Passing in a fixed XML file to test the new format versus changing the code to generate it that way.

By choosing a simple solution *now*, the value is that we can get to evaluating the results and downstream impact of our ideas sooner rather than later. Once we determine that our solution will work, then we go about implementing it correctly. At times, though, we discover that the idea didn’t work as expected. So off we go to look for another solution.

So, simplicity can also be very useful when trying to quickly and cheaply determine the best course of action in creating a viable solution to some aspect of a problem you face.

The “Process Folks” need to walk fine lines of balance in the world of software application development, IMHO…

While process is good, it is not an end-all. In factory work, Taylorism-based processes can be very valuable. In knowledge work, they can be very stifling and counter-productive. For so long, folks have tried to break up software development into factory-like chunks of processes. If you have that kind of software work, then automate it with a tool, not a human . Otherwise, much of what we do — be it creative or inventive or engineering — needs a much looser set of processes. The smallest amount to ensure “Done Means Done” — and to the right degree of “-illity”. Which is no small feat to express just how good a design needs to be, just how much flexibility is needed, how much maintainability, just what is quality code, balancing ROI of time spent getting code out and time in the users hands for getting feedback sooner, etc.

Striking the balance is part of the engineering mindset; but this requires good inputs from many sources, including stakeholders, marketing, users, architects, business folks, infrastructure, tech support, QA, etc.

Okay, so there are lots of complaints about SCRUM MASTER certifications being handed out like expensive candy. But is that really what the complaint is about?

Or, is it something else?

1. Scrum, being primarily about simple techniques for managing a project, maybe really does only take two days to master? (Which I think is believable.)
2. Quite possibly, most of the dissent and gnashing of teeth could be around *assuming* mastering scrum means that developing a working software application naturally follows?

#2 does, quite frankly, involve a whole (heck of a) lot more than the world’s best scrum master.

When I was working at a professional engineering services organization (86-95), we would frequently work on writing proposals to bid on government contracts (Tactical Naval Air stuff).

we had a specific room we outfitted with walls covered in cork board, called the War Room. This room served as a way to put up the overall proposal architecture and the individual sections and allow them to grow over time.

each day, we conducted Daily Stand-up Meetings. the intent was to:

1. to *not* allow people to sit comfortably in their seats,
2. to be able to quickly go through the team’s status,
3. to see if there was anything holding people up, and
4. to keep the vision at the fore of everybody’s mind.

personally, i grew averse to daily meetings of the mundane type at my first job (81-86) at the Naval Air Propulsion Center — where I did R&D on Cruise Missile jet engines. There was a daily meeting at the test facility wing. I remember being excited to have finally “earned my stripes” to be invited to attend this meeting. After all, important topics were presented regarding the test cell usage, scheduling, resource conflicts, etc. Important people would be there adjudicating amongst the competing projects.

However, after a while, I noticed it was often a hollow routine. Many people would sit in the same seats. Walk in the exact same footsteps (+/-5% error), say the exact same things. More ritual than substance. I stopped going except when I had very specific things to discuss for my team’s engine test plans.

So I always vowed to not fall in the trap of having habitual meetings that contained a high percentage of drivel.

To call daily meetings “scrum” is kind of funny now that I know more about rugby :-0 (Thanks to Heinz Kabutz asking his son to comment on the term “scrum” — dangerous, you can break your neck, you don’t want to be in the front row, you need to wear gum guards, because the opposition team will punch you in the face. Ouch!)

Where do your Daily Meetings fall on the scale of mundane to concise (to dangerous)?

There have been some discussions around data modeling and the more costly impacts of database changes.

Doing the right amount of up front work precludes doing the costliest of

refactoring.

Doing enough quality modeling of the domain up front usually makes it

easier to accept change — and to find where the change “goes.”

Making a clear distinction between roles of the different software

artifacts (ui classes, business layer services, domain classes,

persistence management layer, DAOs, etc.) and how they play

architecturally in the implementation, also helps to make it easy to

figure out the impact of a change and where to make the changes.

however, if you have crap for architecture and widely-varying approaches

in different parts of the app, and all sorts of logic spread into the

database (like stored procedures doing business functions that could be

done in objects), then you have crap.

data folks being a “bit defensive” to me says i have to pay more

attention to what i do upfront. if it is costly to do certain parts of

development, then i will adjust my techniques to account for that. i

will have the team work a bit harder, possibly, to ensure that we don’t

thrash the expensive parts of our construction costs.

working with a new development team on a business app to be surfaced through a portal. taking them through an agile project approach. spent the past few weeks doing:

• domain modeling
• feature list elicitation
• looking at the technical architecture (the “how”)
• UI sketches

We then did a first pass at estimating the features… An estimate of how long it would take to build the feature — including everything from persistence to surfacing it on the UI and all parts in between.

“But do we need to estimate building the UIs too?”

That’s a good question. I explained that there were lots of features that contribute to a given UI screen… Therefore, there were lots of “pieces” of estimates from each of those features to be built. These piece-wise estimates of the UI will ultimately contribute to enough hours for the overall UI screen. I think of it as a bottom-up approach to getting a reasonable estimate going.

You can also look at a UI design and estimate it top-down. Check the two against each other if you like…

Not to say that we won’t also have some specific UI work. Just that we do not need to count the full cost of building the feature *and* the full cost of building the UI.

How do you estimate?