Estimation – The Guessing Game

•September 20, 2014 • 2 Comments

InfoQ offers an interesting read on agile planning and estimation. Here are a few key quotes :)

All numbers are based on assumptions. Your figures are only as good as your estimates and guesses – and there may be serious flaws in your assumptions.

If we approve a project based on a year’s worth of work, and we estimate it and we think it is all good, there is a lot of risk inherent in there. But also, and this is worse, we might ditch doing something really, really valuable for the company because we have clumped together all this value into a year-long project and we are making a really big decision – to go or no go – based only on that clump.

Big, up-front project thinking is essentially a lot of assumptions. According to the traditional assumption life cycle, we have business requirements, functional requirements, and they turn into development and then delivery. Actually, these business requirements that we come up with are all assumptions. We do not actually know these things are valid at all. We say, “Well, these are our business requirements. Let’s decide how we will deliver those and get some functional requirements around those”. These are just hypotheses

What happens when Non-Functional Requirements (NFR) are forgotten

•September 19, 2014 • Leave a Comment

“Behind the Curtain of the HealthCare.gov Rollout” offer a few excellent quotes.  I particularly like the quote around the number of concurrent users:

After the launch, HHS officials sharply criticized CMS’s management leading up to the launch of Healthcare.gov. Referencing an email in which a CMS official admits the system could not handle more than 500 concurrent users, Mr. Baitman wrote “Frankly, it’s worse than I imagined!” and Mr. Sivak replied, “Anyone who has any software experience at all would read that and immediately ask what the fuck you were thinking by launching.”

“These bugs were functions of volume…. Take away the volume and it works.”

Clearly from the above some basic principles around project management, software engineering and requirements were “forgotten”

Data Collision

•September 17, 2014 • Leave a Comment

Oracle GoldenGate and HotCache offer an interesting (but expensive) solution to solving certain classes of problem.  Assuming an application stack that is Java, leveraging Oracle Coherence, backed by an Oracles database, where the application stack is installed in two locations, with the requirements for bi-directional replication of data, so each application sees the others data, and can perform actions on the data.  GoldenGate leveraging HotCache provides a mechanism to achieve replication, with the added benefit that not only does the data get replicated between databases (GoldenGate), but that Coherence state is updated as well (HotCache).

Data collision is however the key issues to resolve.  Oracle offers some best practicesBlogs offer some ideas as well.

Scala Parser Combinators

•September 17, 2014 • Leave a Comment

Combinator coolness:

  • Parser combinators FTW
  • Playing with Scala Parser Combinator
  • External DSLs made easy with Scala Parser Combinators
  • Parsing sentences using Scala parser combinator

Implementing Domain-Driven Design

•September 16, 2014 • Leave a Comment

Eric’s Domain-Driven Design (DDD) book is unfortunately not seen enough on software engineers desks.  Hopefully, Implementing Domain-Driven Design will increase the usage of DDD.  Having started to read the book on the last flight, I think Vaughn makes a number of comments in the early pages that are spot on.  Specifically:

“General abandonment of good design and development practices in the Java community” (page xxvii)

“Scrum and other agile techniques are being used as a substitute for careful modelling, where a product backlog is thrust at developers as if it serves as a set of designs” (page xxvii)

“A good portion of our industry is made up of sample code followers, which isnt bad as long as the samples are quality ones” – unfortunately a lot of samples focus on demonstrating API’s, ignoring good design principles. (page 14)

Finally, as is often the case, the small details make a big difference.  An ubiquitous Language offers many advantages, one being the ability to demonstrate the code to domain experts to ensure that the tests are adhering to the ubiquitous language based on the current meaning.

BlackRock Aladdin – 25m lines of code

•September 16, 2014 • Leave a Comment

BlackRock’s Aladdin is an interesting platform, offering dedicated client environments amongst other things.  Anyone know what the codebase is written in?   Coupled of interesting reads on Aladdin:

  • BlackRock’s Aladdin: More Powerful Than Politics?
  • BlackRock’s Aladdin: genie not included

Protocol Buffer – Backward Compatibility

•September 16, 2014 • Leave a Comment

Worth remembering:

  • you must not change the tag numbers of any existing fields.
  • you must not add or delete any required fields.
  • you may delete optional or repeated fields.
  • you may add new optional or repeated fields but you must use fresh tag numbers (i.e. tag numbers that were never used in this protocol buffer, not even by deleted fields).
 
Follow

Get every new post delivered to your Inbox.

Join 658 other followers