Develop A Theme For Your Project – Spock Can Help April 28, 2013Posted by ActiveEngine Sensei in ActiveEngine, Mythology, New Techniques, Personal Development, Problem Solving, software economics.
Tags: ActiveEngine, balance, concentration, focus, Philosophy, Problem Solving, productivity, survival
add a comment
Many times Sensei has said you have to have a theme song for your projects. You may have certainly noticed that Sensei is old school, prog-rock and somewhat metal oriented. Spock’s Beard is a recent discovery and the group has direct roots with Transatlantic.
This latest album is a great source of inspiration, so if you have a ten minute walk ahead of, fire it up and it will get your head straight for serious productivity, creativity, or pure coding marathons.
Fail Often, Fail Fluently March 27, 2010Posted by ActiveEngine Sensei in ActiveEngine, Agile, Fluent, Mythology, Problem Solving, software economics.
add a comment
What do you when your Scenario or User story just sucks? You’ve haggled with your peers over how to implement, the user has changed tunes and come over to your side of things by realizing that they want two things at the same time, but now that you’ve listened to everybody and re-worked your logic, you’ve just spend 6 or 7 extra hours testing. Now, you doubt that anybody really knows what the original intent of your use case was because there are so many different variants and vagaries from all the meetings, emails, hallway tests.
Now succumb to the brain death of Sarbanes-Oxley. Where is the traceability in all the discussion threads? How do you prove that you have what you want and that transactions are preserved and yada-yada-yada it just works? Before the project you thought that your team was like these guys:
Sensei won’t pretend that there is a cool Zen technique to avoid hard work or failure. Maybe this type of failure of communication is a test of your core skills and your “fluency”. Look at the Elvis’ team. They’re practicing. They’ve been over the material again and again and again. That’s three again’s for each of the yada’s. To get to that point where they can adjust to his direction they’ve done much on their own time acquiring skills. Years of practice and adjustment.
Your project is like that path to acquiring a skill set, gaining mastery, being fluent. You have to build for flexibility, for
change. You CAN NOT give in to YAGNI just because this week you think you know all the answers. You won’t create a fan base that way. And just because something is written down does not mean that it’s set in stone. Remember Moses and the stone tablets? Even though he could part the waters he still had to go up the hill twice. Things will go wrong, but if you put in the time your adjustments, while painful after a long haul, won’t be that bad. 6 hours could have been 6 days. Be thankful you have good partners.
Getting to 11 February 13, 2010Posted by ActiveEngine Sensei in ActiveEngine, Fluent, New Techniques, Problem Solving, software economics.
Tags: ActiveEngine, Bushido, concentration, focus, humility, new thinking, Problem Solving, survival
add a comment
In the past Sensei has written insane tomes regarding time travel and how your best intentions really get you no where. The story today is about getting to 11, which as Nigel says is one more than ten, putting you over the top. Consider for a moment the times that you really think you’re like this guy to the right. Yep, you think you have a Martin Fowler sized audience when you are coding. The scientists of the future will study my code and say “Here, this is the start of the great insight. How interesting.” In reality you are like Spinal Tap, unaware of how absurd you can be. Code too complex, but it goes to 11! Most blokes keep it at 10, but then you need to put it over the top take it up a notch. That extra notch. That’s 11.
Here’s a thought – what about 6? Is it viable? Can you be flexible by doing a 6, just good enough to not paint yourself into a corner? “Perfection is a process, viable is an end state.” As a developer you may not be able to judge what 6 is. If you’re in tune with your fan base you’ll know but that can only come from wisdom born out of great mistakes. For those of you who study Budo you may recall the concept of short and long and how relative scale can shift your advantage. Your opponent may have a sword and you only a dagger. Short and long makes a big difference, but you can alter that equation with small maneuver. Once you’re inside and beyond the sword’s curring range you have the advantage, as your dagger is now long enough to finish the skirmish. Change the scale.
Years back Sensei was given the task of reducing shelf space utilized by paper by 25%. The CFO arrived at this goal via scientific method. It was scientific since at Sensei’s company if you don’t do what the CFO said it is axiomatic that you were in deep doo-doo. Laws of hierarchy and all. Now imagine rooms filled with documents related to contractors, account-receiveables, human resources, legal contracts, project management etc. Yah, DISPARATE is the word. Not meta data, just a meta-mess.
Now in the best of all worlds where you need to get to 11, you would have time to survey all document types and refine each attribute set before you design your system for document categorization. This foundation becomes your data model in a database and many would claim that you should a create data table per document type to house the varying number of attributes. But you have 2 million sheets of paper to scan and in 12 months re-construction at your offices begin so you need to be able to walk into a room and quickly categorize all documents, throw them into boxes, scan them, and automatically assign the meta data to the document and store the thing. Oh, and if you miss a document type or need more attributes you don’t want to go back to your database, add or modify a table, re-gen your data access layer, add the attribute to your screen all before your adjust your categorization. And remember, you need to ship out 80 to 100 boxes every 2 weeks so you need to keep the data entry flowing. Finally, you are told that some projects can have up to 50 different types of documents, but no one is sure to what degree the project documentation is complete so the number of document types per project is not known and NOBODY HAS THE TIME TO GO THROUGH THE SHELVES AND CREATE DOCUMENT TYPES BEFORE ANY DATA ENTRY IS POSSIBLE!
Play the song, ’cause it adds to the excitement!!
Several key decisions solved this mess, and the solution was simple enough that temps could walk into a room categorize and pack documents into boxes for scanning. The error rate ranged between 1 – 5% per department. These were not solutions cranked up to 11, they were 6’s:
- No change to database schema or screens will be made, ever. A document was modeled with four tables with a base Document table, Document- Type table, Document-Attribute table that contained all attributes per Document-Type and finally a Document-Attribute-Value table where the meta data was stored. This way each Document-Type could be be created with simple data entry. One data entry screen that could create data controls on the fly per attribute type developed.
- Each document shall have a bar-coded coversheet. Nothing gets scanned without meta data. EVV-ARR.
- Import data from existing systems. The meta data for your documents resides in many of your accounting, job cost, and budget systems. Once document types are known, dumping data from accounts receivable and / or accounts payable allows your to assemble thousands of cover-sheets for all invoices. Quite literally you create a stack of paper for all possible types of invoices for all accounts, walk into a room, pull documents of the shelf, attach coversheets, and keep the sheets you didn’t use. Now, since the unused sheets have a bar-code, run these through you bar-code reader and create delete records for what you didn’t use. Now you have a complete accurate manifest of what was on the shelf and what was packed away. When the scanned images come back you can inspect them against the manifest.
- People can work better with paper. As stated in the last bullet point, creating all possible types of document coversheets per account or project and printing them allows you to quickly categorize all documents. With minimal or no data entry and a stack of coversheets, anyone now can go through shelves and associate the coversheets with the appropriate documents. In other words, the subject matter experts have a tangible, traceable system that they can hand off and supervise someone who can do the grunt work. Not sure where you finished with your categorization? Just look at your stack of coversheets. Want to inspect accuracy, grab a document and compare it to the categories printed on the coversheet.
What? Process management with paper ? That sucks! No it really doesn’t. You see, a 6 to you really is an eleventy-one for your user community who is really busy. Yep, you have to be smart with your database design by focusing on one key area and that’s it. The rest of the effort is imports with SSIS packages, CSV files, and printed coversheets. But it’s easy for the users to use paper, and that keeps a flow going. 2 million sheets of paper scanned in a year. Maybe a 6 isn’t all that bad after all.
Chang-chang-a-ching-changa-langa-langa: Why Your User Community is Fluent in English and You Are Not the King February 6, 2010Posted by ActiveEngine Sensei in .Net, ActiveEngine, Business Processes, Coaching, Fluent, Problem Solving, software economics.
Tags: ActiveEngine, ActiveEngine Sensei, bad software, balance, communication, new thinking, Problem Solving
1 comment so far
Get ready for the sound of one hand clapping, but first, fire off the song as it get’s your head straight.
Some of you want to be Elvis too much. Sensei’s going to tell you a story so you know what he’s talking about. You see, users of your apps are waaaay smarter than you, and spend more time in their fields than you ever hope to do. You need a little love. It’s called fluent interaction. Fluent. Interaction. Lord have mercy.
Process mapping helps, but in the end that takes you to overly scientific abstractions, and while user stories help some they, too, stray with you as the sole author. You in the chair, just the important details from the user, but mostly you. Should you consider yourself not Mort but an Elvis, you may want to ask yourself what Elvis you want to be:
|Kick-ass Karate Elvis
||Drug Ridden Elvis Wanna Be
Back to the story. Last episode, in a spate of productivity and a dose of SQL-NoSQL fever, Sensei created a slim document management solution that can be quickly applied to an existing framework with minimal impact to database schema and code base. Sitting around the conference room table the comment arose from Annie, the project lead from the Sales group:
“Why do I have to save a commission record first before I can attach a document? That interrupts my flow. I want to put in everything that I want and save, period. No dialog box thingy prompting to save first, come back and do something else. Why can’t we just do it”
Long silence. The sound of one hand clapping.
One of Sensei’s report-to’s jumped in: “Because in order to associate the document to the commission you have to save that commission first in the database, then take the id from the record and associate it document. This allows you to retrieve it later on.”
Annie: So. Can’t that just happen behind the scenes? If it’s two steps the sales gal won’t do it. She’s got calls to make.
Ssensei drifted out in research land, or as normal people call it, he spaced out for a bit. NetFlix sprang to mind, iPhone too, where you delete, it does it, but you can bring it back. Take the confirmation response out of the equation. Give the user a chance to undo their mess, but don’t get in their way. It’s fun to pretend to be the King, but what a wake up slap. The technology was right, but the user was seeing the benefit because “putting the stuff in was too clunky”. Sensei went and did want Annie wanted. Annie thinks its great. Good technology made better by the user, not the King.
Fluent. Interaction. Lord have mercy. You see, Annie’s right and user stories, UML and other brain death would never capture the essense of her perspective, particularly after she used the software. Yeah, soft deletes are great theory, but you are not thinking like a user. In order to be a better King, you gotta give the concert they want to hear. You have to know that the fans have created you, have shaped your persona. You have to know your fans, almost be them.
Elvis had a come back concert in 1968 but it almost didn’t happen as there was a huge fight with NBC. The network insisted that the show would be like a Bing Crosby special given that the air date was during the Christmas holiday season. Elvis wanted an intimate environment where he could perform up close, live with his fans. He thrived off of close contact with his fans. Know your audience. Elvis was right, and it helped re-launch his singing career and revive his legend. It was one of his best performances. For the fans.
You need to listen to your users. Spend the time to hone your craft, but work even harder to make them fans. What do they need? Is the concert for them or for you? Are you learning just to be smart or for their benefit? Fluent solutions require interaction with the fans. Thank you. Thank you very much.
Why Your Code is a One Way Time Machine October 19, 2009Posted by ActiveEngine Sensei in ActiveEngine, Agile vs Waterfall, Mythology, Problem Solving, software economics.
What type of duress are you under? The unfortunate among us have been sentenced to slavery by our evil nemesis from the past. We all have this enemy, and at one time or another have succumbed to the enemy’s evil plot. The enemy from the past is YOU.
When you sit down to create a solution, you need to balance solving the problem with being able to maintain and implement changes to the logic you have selected. All logic changes, and there are very few times when you have the finite scope defined to be able to accommodate new ideas. “Rewrite!” is the cry of many who have written good solutions that have solved the problem but more than likely are not very maintainable. “Broken Cardinality” is the bane of all DBA’s, and this is very serious indeed. Sensei can’t help you with that – go beat your business analyst who didn’t drive home the rules of relational databases!
What Sensei will say is put your tools after you think you’ve solved your users problems in a two week sprint, step back and project into the future: will this code be readable; can you augment the logic without altering the methods; will you be happy with yourself at midnight trying to fix something? Addressing these concerns helps you maintain your solution.
The real challenge is to help yourself next year. The-future-you needs your help, but The-future-you will hate you if you misconstrue YAGNI in your design phase with avoid-refactoring-at-all-costs while you code. Forget the sprint. Putting something into a customers hands too soon masks the complexity of what you have done for them and undersells your true talents. They’ll be happier if you can quickly implement changes without impacting the existing environment. Congrat’s – The-future-you just bought a beer!
The Economics of Developing iPhone Apps August 6, 2009Posted by ActiveEngine Sensei in ActiveEngine, software economics.
Tags: bad software, iPhone, new software, new thinking, paradigm
Sensei has an iPhone and it is indeed a great technological achievement. It just works. Another attractive aspect to the iPhone is the lowe priced software available from the App Store. We have all heard of the stories of the kid who made $40K by creating an app and selling it. At Coding Horror, Jeff Atwood posted his thoughts regarding the effect of lowering the cost of a software product and how that can create a jump in sales. In short, the lower priced software makes up for the loss with volume.
The Economics of Protecting the Red Shirts July 29, 2009Posted by ActiveEngine Sensei in .Net Development, ActiveEngine, Business Processes, Coaching, Design Patterns, Mythology, Personal Development, Problem Solving, software economics.
Tags: ActiveEngine, bad software, communication, Data Stewardship, new thinking, paradigm
Recently I came across this post from a fellow lamenting the lack of interest on the part of .Net developers in architecture solutions such as IoC, Dependency Injection, ORMs, and the like. This stood out in stark contrast to Java developers who this person interviewed, who either were conversant with the technology or were interested enough to pursue informing themselves further. Some call this the result of Drag -n -Drop design as laid out in a post by Greg Young, a Microsoft MVP and .Net developer who has specialized in high performance applications. Greg maintains in his post Java vs. .Net Developers that drag and drop is mis applied and there needs to be an greater effort the isolate the cases where it is mis used. This practice has arisen, he maintains, from poor training and lack of awareness of other development platforms. (more…)